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.

1. AppLab Money Incubator:
Case Study Part 2
Phase III: Concept Development
January 2013

2. Background: Introducing the project
The AppLab Money Incubator brings together partners with diverse strengths. All are
interested in improving the financial well being of the poor through innovation.
CGAP Applied Product The Grameen Foundation
Innovation Program AppLab Money Incubator
CGAP is supporting providers across the globe Grameen Foundation’s AppLab Money was
to apply design thinking methodology to launched in October 2011 in conjunction with
develop better products for the poor. The first CGAP and MTN Uganda (MTNU). The incubator
project was launched in Uganda, through a was set up to spur innovation in the mobile
partnership with Grameen Foundation’s financial services space. The program has two
Application Laboratories (AppLab) in October main aims: (1) to scale 1-2 innovative products
2011. that are attractive to poor customers but also
commercially viable for MTN.
Additional product innovation work has taken
place in Mexico with Bancomer and in Brazil This presentation focuses on concept
with Bradesco. For more information, watch development. The Research and Ideation phase
CGAP’s video about the API project in Mexico is covered in case study 1, available on the
and check out CGAP’s blog series on the topic. CGAP blog.

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 Approach
1 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 prototype
o Develop project plan program – identify ideas into robust questions to answer and conduct full pilot
objectives and concepts through user tests with large group of
o Align objectives with develop research (user users
key stakeholders approach o Assess feasibility and interaction, user
commercial viability interface, messaging o Work with various
o 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, fin
o 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 prototypes
Phases 1 & 2 covered under Case Study 1
Focus of Case Study 2
available from the CGAP blog

4. Background: Key insights from concept development
Several insights emerged from the concept testing phase, which are covered in this case
study:
Test with users Putting concepts into the hands of users in a form with which they can interact as quickly
early 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 properly
lead to powerful
analyzed how much it can enhance the product development process.
products
Products die for
Concepts can be shelved for reasons like lack of partners to perform critical
non-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 important
business models
to develop and vet out business models early in the process.
early

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. Background: Where we left off
As part of the end of Case Study 1 we had completed phases 1 & 2. These entailed a
number 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. Enhance: Short-listing ideas into robust concepts
As part of the concept development phase, eight concepts were considered by multiple
stakeholders 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. Enhance: Two short-listed concepts were shelved
As 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. Enhance: Two short-listed concepts progressed
As the concept validation phase progressed, two of four concepts, me2me and
zimba, 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. Assess: Commercial viability
We 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. 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 customers
We presented customers with several pricing and reward
options and asked them which one they would prefer
We tweaked the models based on customer feedback
before presenting to scaling partner MTN

12. Assess: Preparing for user testing
A number of questions and hypotheses were identified that would guide our
interaction 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. Conduct: Low-fidelity testing using tablets
To get early feedback on the concept and menu, and show users how
a 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 concept
Low fidelity prototypes can be an
easy and useful way to engage users
and explore their early understanding
of a product

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. 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 entire
Interaction between members group who then decided if they wanted to fill
provided insights into product request, and how to contribute
features; e.g., users haggling
over interest rates revealed
that they preferred the system
to set the rates, and they
agreed that a “fair rate” was
5-10%/month

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
themselves
Business model changed when team learned that customers were willing
to pay for a savings product, but only if they rewarded for using it

17. Identify: Introducing the service design method
After initial user testing, we brought in a service designer to help think through the full
user 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 and
public policy perspective legal perspective
17

18. Identify: Developing the service design strategy
Service design uses a holistic approach to understanding the landscape. Models such
as 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. Identify: Using service design models
Service model diagrams show a product in its full context and forced the team to think
about the entire experience of usage and not just the concept
An interaction pathway shows different paths or Different stakeholders are interested in different
ways that a user can experience product. It outcomes in relation to new product. While most
shows 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 from
customer support, enabling team to design the onset is key and will require varying levels of
whole experience . engagement.

20. Survive: Challenges for MTN and for incubation
As the team was still building out the blueprints, fraud was discovered at MTN. The
company focused energy on managing the situation, and put innovation on the
backburner.
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. 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 concept
The team sits in MTN’s offices and maintains our existing
relationships. We continue to work our products into
MTN’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. Survive: Getting the tentative go-ahead
MTN tentatively placed two products on the product roadmap, though some
executives 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. Survive: Presenting the business case
We were given 10 minutes in front of the decision-making committee to pitch the
product and address outstanding questions
Using customer insights drawn from MTN’s
We also pulled data from our
own data, we demonstrated the opportunity
own research to make clear the
for these products based on current customer
business case for these products
behaviors

24. Survive: Focusing on next steps
The MTN committee was aligned, and the incubator team moved from driving to
supporting 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. 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. 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. 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 Approach
1 2 3 4 5
Research and Concept Product Launch
Set-Up
Ideation Development Testing Planning
o 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 pilot
o 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, user
o 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 plans
o 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 CGAP's blog

28. Next Steps: The future
As the team moves to a commercial pilot and launch, we will not be able to share as freely
due to reasons of confidentiality.
However, we will post updates on CGAP's blog
and CGAP will synthesize learnings on the
commercial roll-outs across API projects and
share these at a later time.