CGAP and Grameen Foundation AppLab Money Incubator: Case Study Part 2


Published on

CGAP and the Grameen Foundation share insight from the concept development phase of the money incubator. Eight concepts were considered and tested by stakeholders and potential users. Four were shortlisted for validation. Two of these four were shelved for non-user related issues. Me2Me and Zimba were selected for development. Storyboards and simple prototypes aided the testing phase.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Would like to fix this text changed the flow
  • Add the number of months for each phase? As per CGAP comment will fix the design of this
  • Can make this a build like the others before
  • Will make this look better
  • Move de-scoped concepts to appendix MC?Will fix the text boxes so they are cleaner
  • Will make text nicer
  • CGAP and Grameen Foundation AppLab Money Incubator: Case Study Part 2

    1. 1. AppLab Money Incubator: Case Study Part 2 Phase III: Concept Development January 2013
    2. 2. Background: Introducing the projectThe AppLab Money Incubator brings together partners with diverse strengths. All areinterested in improving the financial well being of the poor through innovation.CGAP Applied Product The Grameen FoundationInnovation Program AppLab Money IncubatorCGAP is supporting providers across the globe Grameen Foundation’s AppLab Money wasto apply design thinking methodology to launched in October 2011 in conjunction withdevelop better products for the poor. The first CGAP and MTN Uganda (MTNU). The incubatorproject was launched in Uganda, through a was set up to spur innovation in the mobilepartnership with Grameen Foundation’s financial services space. The program has twoApplication Laboratories (AppLab) in October main aims: (1) to scale 1-2 innovative products2011. that are attractive to poor customers but also commercially viable for MTN.Additional product innovation work has takenplace in Mexico with Bancomer and in Brazil This presentation focuses on conceptwith Bradesco. For more information, watch development. The Research and Ideation phaseCGAP’s video about the API project in Mexico is covered in case study 1, available on theand check out CGAP’s blog series on the topic. CGAP blog.
    3. 3. Background: Where we are in the process We pursue a five-phase process to setting up an incubator, and Case Study 2 focuses on learnings from the Concept Development Phase AppLab Money Incubator: Product Development Approach1 2 3 4 5 Research and Concept Product Launch Set-Up Ideation Development Testing Planning o Plan research o Enhance short-listed o Identify key o Finalize prototypeo Develop project plan program – identify ideas into robust questions to answer and conduct full pilot objectives and concepts through user tests with large group ofo Align objectives with develop research (user users key stakeholders approach o Assess feasibility and interaction, user commercial viability interface, messaging o Work with variouso Hire complementary o Execute research of key concepts and language, etc.) functional teams to team create launch plans o Process insights and o Conduct low-fidelity o Conduct user testing (marketing, sales, fino Prepare for research resulting testing (e.g., using and iterate on the ance, legal, risk, etc.) phase opportunities paper prototypes) prototype o Identify ongoing o Identify long-list of o Identify short-list to o Work with M&E plan ideas and prioritize test with users stakeholders to begin short-list for concept through medium- technical integration development fidelity prototypesPhases 1 & 2 covered under Case Study 1 Focus of Case Study 2available from the CGAP blog
    4. 4. Background: Key insights from concept developmentSeveral insights emerged from the concept testing phase, which are covered in this casestudy:Test with users Putting concepts into the hands of users in a form with which they can interact as quicklyearly and often as possible is paramount. It helps provide critical feedback and ideas for improvement. Good products Innovative new products thrive in a service ecosystem. Service design helps identify key require great stakeholders and their interests, user experience and context, etc. that are critical for service design successful product design.Innovation stalls When an organization is in crisis, their energy is focused on managing the situation. As a in crisis result, innovative initiatives take a backburner. Org data can Many larger organizations do not know the power of the data they hold, and if properlylead to powerful analyzed how much it can enhance the product development process. productsProducts die for Concepts can be shelved for reasons like lack of partners to perform criticalnon-user related role, regulatory risks, etc. It is not only user related issues that kill good ideas. issues Develop For a partner to champion a product, the business case must be apparent – it is importantbusiness models to develop and vet out business models early in the process. early
    5. 5. Case study 2 outline Background: where we left off Enhance: turning ideas into concepts Assess: feasibility and commercial viability Conduct: low fidelity tests and paper prototypes Identify: short list of ideas and test them with medium fidelity prototypes Survive: getting through and thriving in a turbulent environment Reflections: what we learned Next steps: what the future holds
    6. 6. Background: Where we left offAs part of the end of Case Study 1 we had completed phases 1 & 2. These entailed anumber of activities: Setting up the incubator Planned project, hired a team and prepared for the research Planning & executing the research Planned and executed the research in a flexible manner using different methods Processing insights and resulting opportunities Identified themes emanating from the research and the potential opportunities they highlighted Translating ideas into product concepts Collected many product ideas, organized, filtered and fleshed them into concepts Soliciting feedback & identifying top concepts Got feedback from various stakeholders and identified concepts with best potential for success
    7. 7. Enhance: Short-listing ideas into robust conceptsAs part of the concept development phase, eight concepts were considered by multiplestakeholders and tested with potential users. Four were short listed for validation mobile data CKW data for beat the bank me2me for credit agri-lending warehouse virtual savings social vetting insurance lottery e-receipts group: zimba 7
    8. 8. Enhance: Two short-listed concepts were shelvedAs the phase progressed, two of four concepts were shelved for non-user related issues Why it was shelved:  There was a delay in accessing the data needed to create a scoring measure from a partner  The team realized that creating and testing a scoring algorithm that would be adopted by different stakeholders in the financial industry would take much more consultation and effort than project period allowed mobile data for credit Why it was shelved: GF had not collected sufficient data, repeatedly, over time in the CKW database to create a measure for the 72,000 + farmers we have registered The team realized the need to engage potential agri-lenders to create buy-in and agreement over types of information to be collected would take more time than the project period CKW data for allowed agri-lending 8
    9. 9. Enhance: Two short-listed concepts progressedAs the concept validation phase progressed, two of four concepts, me2me andzimba, were selected for development. Why it was progressed:  Low risk for partner because user funds are not intermediated  Large opportunity given that saving is widely undertaken for different purposes  Lack of viable competition or formal alternatives that can provide secure service at low cost  Was easiest concept to implement without need for more partners to get involved me2me Why it was progressed: Credit for different purposes was the number one need expressed by most users that we talked to in the field Individuals are highly social, operating in different networks, many of which already provide credit Most credit arrangements within the community are informal, making it difficult to track borrowers or reward lenders virtual savings Formalizing credit processes would make it easier to tap into group: zimba new sources of credit from third parties like banks
    10. 10. Assess: Commercial viabilityWe assessed many business models – including pricing and reward options – for a back-of-the-envelope assessment of how products could be monetized Sample pricing options Sample reward features Some trade-offs Returning fees  We needed to balance the need Transaction fees for partner profits with the as airtime knowledge that poor customers Monthly fee for could not afford to pay high Providing interest prices transactions  We needed to encourage “Freemium”– monetized Offering insurance for positive customer behaviors through ads loyalty through reward and discourage negative ones through “Freemium”– monetized Holding a lottery to penalization by working with partners compensate for fees  We needed to balance the Fees for Pay for one service, get actual pricing of the product bundled services another free in return with the perceived value
    11. 11. Assess: Testing the models in the field with customers We built simple models and then tested hypotheses on willingness and ability to pay for product in the field with customersWe presented customers with several pricing and rewardoptions and asked them which one they would prefer We tweaked the models based on customer feedback before presenting to scaling partner MTN
    12. 12. Assess: Preparing for user testingA number of questions and hypotheses were identified that would guide ourinteraction with various groups of users Do users understand the product? Would customers pay for the product?How can the product be changed to better Which segment will use the product? How suit their needs? will they use it?
    13. 13. Conduct: Low-fidelity testing using tabletsTo get early feedback on the concept and menu, and show users howa product worked, we built the user interface on a tablet We first aligned on the menu options and flow through paper prototypes which were tested internally with office members We then revised the menu based on internal feedback and programmed on a tablet The tablet was used at concept stage not to test functionality but to provide customers with an early overview of the product and its features, and to test their understanding of the conceptLow fidelity prototypes can be aneasy and useful way to engage usersand explore their early understandingof a product
    14. 14. Conduct: Scenario prototyping with storyboards Storyboards were also used to delineate usage scenarios, and contextualize a product in the daily life of a user Storyboards are rich and fleshed out descriptions of product usage within a given situation and context They are presented to users to garner feedback on the concept and value proposition They provide a cheap and effective means to evaluate the concept without building up a full prototype
    15. 15. Conduct: Interactive service prototyping Both storyboards and tablets facilitated interaction amongst users during testing, which led to valuable feedback For virtual savings group, we had customers create their own groups and assign one to be a borrower The borrower made a request to the entireInteraction between members group who then decided if they wanted to fillprovided insights into product request, and how to contributefeatures; e.g., users hagglingover interest rates revealedthat they preferred the systemto set the rates, and theyagreed that a “fair rate” was5-10%/month
    16. 16. Conduct: Feedback fed into design process Feedback coming from the field was used to flesh out the concept and to build and improve the business model and improve the product concept and business model An auto-deduct feature was eliminated from the concept after users made clear that they had more control over their cash when making payments themselvesBusiness model changed when team learned that customers were willingto pay for a savings product, but only if they rewarded for using it
    17. 17. Identify: Introducing the service design methodAfter initial user testing, we brought in a service designer to help think through the fulluser journey and to help take final decisions on outstanding considerations Service design focuses on creating innovative services that are desirable for those who will use them, viable for What’s those who deliver them, and that are DESIRABLE possible to implement from a From a user and a technological and legal perspective community perspective SERVICE What’s DESIGN What’s VIABLE POSSIBLE from a business and from a technology andpublic policy perspective legal perspective 17
    18. 18. Identify: Developing the service design strategyService design uses a holistic approach to understanding the landscape. Models suchas a “service blueprint” capture the conceptual design and describe the intent, context,user experience and delivery of a service. In different sessions, the team explored user feedback from the field and made final design decisions on product features The decisions, arrived at through a co-design process, were captured in the final service blueprint
    19. 19. Identify: Using service design modelsService model diagrams show a product in its full context and forced the team to thinkabout the entire experience of usage and not just the conceptAn interaction pathway shows different paths or Different stakeholders are interested in differentways that a user can experience product. It outcomes in relation to new product. While mostshows how different features would be used in portend benefit, some do have risks associated.different situations. It also extra touch points like Identifying and managing these outcomes fromcustomer support, enabling team to design the onset is key and will require varying levels ofwhole experience . engagement.
    20. 20. Survive: Challenges for MTN and for incubationAs the team was still building out the blueprints, fraud was discovered at MTN. Thecompany focused energy on managing the situation, and put innovation on thebackburner. We needed to step away from the testing to re-introduce our initiative to new contacts within MTN By necessity, MTN executives needed to focus on their primarily priority at hand – addressing the fraud and securing the system Innovation efforts can be a difficult to progress in normal environments; in times of crisis, R&D is rarely not top of mind
    21. 21. Survive: Working within the partner’s process The team engaged with the marketing and product departments and worked within MTN’s approach to product development to progress the conceptThe team sits in MTN’s offices and maintains our existingrelationships. We continue to work our products intoMTN’s process for bringing new products to market. We provide MTN new tools that they can integrate into their existing product development process to capture insights more quickly and cheaply
    22. 22. Survive: Getting the tentative go-aheadMTN tentatively placed two products on the product roadmap, though someexecutives still had concerns we needed to address Our partners at MTN presented the concepts to the product and services committee—which makes the decisions on all new products Two products were tentatively placed on roadmap, though there were concerns: Some felt that regulatory approval would be needed to launch the product Others thought one concept was far too complex for the current platform to handle Additionally, some believed that MTNU needed to focus on addressing the core business following the fraud, not developing new products
    23. 23. Survive: Presenting the business caseWe were given 10 minutes in front of the decision-making committee to pitch theproduct and address outstanding questionsUsing customer insights drawn from MTN’s We also pulled data from ourown data, we demonstrated the opportunity own research to make clear thefor these products based on current customer business case for these productsbehaviors
    24. 24. Survive: Focusing on next stepsThe MTN committee was aligned, and the incubator team moved from driving tosupporting the innovation process The team is now finishing a high-fidelity prototype and planning more sophisticated interface testing with MTN Additionally, we are supporting MTNU as they scope out the specifications needed to incorporate this product in their systems
    25. 25. Reflections: What worked well Working ourselves into MTN Product and service design process expertise We re-established our relationships in the The service designer forced us to look at our midst of a crisis by working closely with product in new ways and also to make existing contacts who were not implicated decisions about its features Product testing tools Failed fast and didn’t look back We developed testing tools that allowed for We killed products when we had to, felt remorse only rapid feedback from customers on products temporarily, and focused developing the chosen ones. Communication of progress We survived the crises We created weekly briefs that allowed others We called in close contacts at MTN and pushed to follow our process product along even as the dust settled…. Made use of company data We used MTN’s numbers to help us convince their product and services committee that our products were viable
    26. 26. Reflections: What we learned More integrated into MTN’s Better job of selling value of data processes mining We should have had a better understanding of Find other ways to “sell” the value of data and the MTN process from the beginning and pushing earlier for access ensured that we worked ourselves into it Become trusted partner across Dedicated product design person organization We should have had a dedicated service By increasing our contact base across the designer lead the process from the very organization, we would have been better beginning instead of relying on a slew of prepared for the crises consultants Better planning within flexible process We needed to be nimble and flexible as we were learning and we should have allowed more time for deviation in the initial planning
    27. 27. Next Steps: Product testing In the product testing phase we test the concept on the phone through a basic USSD-enabled prototype AppLab Money Incubator: Product Development Approach1 2 3 4 5 Research and Concept Product Launch Set-Up Ideation Development Testing Planningo Develop project plan o Plan research o Enhance short-listed o Identify key o Finalize prototype program – identify ideas into robust questions to answer and conduct full piloto Align objectives with objectives and concepts through user tests with large group of key stakeholders develop research (user users approach o Assess feasibility and interaction, usero Hire complementary commercial viability interface, messaging o Work with various team o Execute research of key concepts and language, etc.) functional teams to create launch planso Prepare for research o Process insights and o Conduct low-fidelity o Conduct user testing (marketing, sales, fin phase resulting testing (e.g., using and iterate on the ance, legal, risk, etc.) opportunities paper prototypes) prototype o Identify ongoing o Identify long-list of o Identify short-list to o Work with M&E plan ideas and prioritize test with users stakeholders to begin short-list for concept through medium- technical integration development fidelity prototypes Phases 4 & 5: Look for updates on CGAPs blog
    28. 28. Next Steps: The futureAs the team moves to a commercial pilot and launch, we will not be able to share as freelydue to reasons of confidentiality. However, we will post updates on CGAPs blog and CGAP will synthesize learnings on the commercial roll-outs across API projects and share these at a later time.