That conversation stuck with me. In the moment, I suggested that he think about inverting that statement: how can he build software that users are compelled to get their hands on and use?

I’ve been thinking about Google a lot recently (partly spurred by reading In the Plex), and in particular the combination of heavily data-driven decision making and their intense focus on doing what’s right for users. There’s a fine balance to strike in building software, weighing understanding what users want to do and what will make them happy while innovating in ways that users might not even know they want. We struggled with this at Mifos, and often ended up in the no man’s land between the two ends of the spectrum, dragged down by a never-ending list of feature requests while trying to build for the future of microfinance. In the end, we didn’t do either one terribly well and that hurt our market traction.

The right fundamental principle is to find user pain and solve it, whether the user knows that pain exists or not. This assumes that pain is indeed pain… if solving the pain doesn’t get noticed by users (whether measured by clicks on ads or by hardcore business process improvements in a microfinance institution), you probably were wrong about the pain point. This is where metrics and data come in, and picking the right metrics is critical. Collecting data that you can sift, mine, and find interesting correlations in helps a ton – you can test multiple hypotheses quickly – but it’s not always easy to collect user data. This, too, was a real struggle with Mifos and it’s something that Google very clearly both a) understands well and b) is really well positioned to act on.

For budding software entrepreneurs like the guy I talked to at Ashesi, the right approach will evolve as his business evolves. By starting with a few core principles (find the data that matters and understand it, ruthlessly make users happy) he’s likely to succeed. If he instead goes down the path of “I built something cool, now I have to convince people to use it” he’s likely to find it much harder to get real traction.

Google Voice solves that really easily, and doesn’t require me to change my primary US number. Instead, I set up a Google Voice number and entered a code to forward from the AT&T phone to the Google Voice account for all voicemail handling.

Now, if you call my US number and get voicemail you can leave a message and know that I’ll get it. Google Voice sends me an email with the audio attachment and also does an attempted transcription. The transcription isn’t great (yet) but it does usually give enough of the gist of the message that I know immediately whether it’s something I need to deal with now, soon, later, or never.

Simple, works great, and it’s free. Totally sweet.

Now if they only had international call forwarding at reasonable rates…

However, a big part of the value that I see in mobile apps – both in general and specifically here in Kenya – lies in the ability to aggregate apps into “meta-apps” and in the potential value of the data that is flowing through the apps. Any app developer who moves data from the phone to somewhere else will have to do something on the back end to store and process that data, and structuring the data from the beginning with analytics in mind will prove beneficial in the long run.

Consider a health application that delivers pre-natal tips to pregnant women (such as Grameen Foundation’s MoTeCH initiative). The primary purpose of an application like this would be to provide information to women that helps them to ensure the best possible health outcomes for themselves and their children. Beyond that, though, the application could answer questions that the mothers ask via an SMS or USSD interface. There’s some complexity in building the parsing engine needed to interpret the questions and find the right answers to send back, certainly, but it would also be super valuable to build the back-end in a way that the organization could analyze the questions being asked, cross-reference that against the information being sent out, and make better decisions about how to further improve the outcomes of the app.

Apps that involve mobile commerce, or politics, or just about any other domain are likely to have very interesting analytics implications. Further, many apps may have interesting cross-referencing possibilities. For example, with a common back-end that serves both health and financial purposes (and gathers health and financial data), the aggregators of that data will have the ability to mine the data to find correlations (maybe between savings and health?) that can be used to improve the apps and to identify new potential apps for specific target markets.

The key thing in getting interesting use from the data – including usage patterns, data collected, and the like – is getting enough scale to make the analytics possible. Building for the back-end from the beginning rarely makes sense, and instead scale will come from killer apps that get hundreds of thousands or millions of users over time. A couple of apps at scale, integrated on the back-end, would provide an incredible dataset for the application developers and other stakeholders.

For my current work looking at Mifos possibilities in Ghana and Kenya, this becomes very interesting. Mifos could become the back-end platform for a wide variety of microfinance-oriented apps (and eventually for other poor-focused apps). These might include access to account information for microfinance clients, loan officer apps to improve productivity and security, and management tools that tell MFI executives what’s happening in their organization and where their attention is needed. Mifos could be the back-end for those apps even if the MFI wasn’t using Mifos as its core technology platform.

The business model, like most technology ventures, may be the hardest part. If we were to pursue this idea, getting the apps and other services to scale is the necessary pre-requisite to building a business on the back-end data aggregation and analysis for both individual MFIs and (with the right privacy protections) for meso- and macro-level stakeholders. A methodology like the Customer Development Process that starts with a strong product vision but then uses a rigorous approach to testing hypotheses and building a viable business model before trying to get to scale would be key to making this work.

The goal with the plan I’ve been working on in Ghana is to help bridge that gap, creating stronger software developers and entrepreneurs that lead to stronger software companies. One idea that we’re considering is the creation of a Software Entrepreneur Residency program within a larger African Center for Open Source and Software Entrepreneurship (ACOSSE). This is akin to a medical residency, but for software entrepreneurs instead of medical doctors.

The key elements of the residency program would be:

• An 18-24 month commitment on the part of the resident
• Work on a full-time, paid basis in a software company affiliated with ACOSSE
• Work on real problems that move the business forward
• Rotate through multiple disciplines; for example, spend 3 months in test, 3 in development, 3 in product management, 3 in customer support, 3 in sales, etc.
• Work under supervision of a designated mentor who helps both with the work and with career and personal development
• Participate in continuing education programs on software engineering and entrepreneurship (run by ACOSSE)

The residency would smooth the transition from academic learning to the deep-end of real-world startups, and would significantly broaden the exposure of software engineers to the entire cycle of the business. A software engineer with a great idea who has been on sales calls, fixed bugs, built a test plan, and helped customers with support issues will have a much better idea of how to build both a business and a great software product.

(Pixar appears to have an internal version of this for recent grads as well)

Scenario D: VC/R&D Lab in Kenya

The basic idea is derived from MPOWER Labs (and MPOWER Ventures), or at least from my understanding of how they work based on their website. The basic idea is to create an investment firm where an initial portfolio company provides a shared set of resources across the other portfolio companies. These shared resources might include people talent (an experienced CTO who floats across 5 companies), software and business tools and methodologies, support functions, and R&D.

What makes this interesting to me is that it solves a couple of fundamental problems I keep seeing in the software industry: a lack of seed stage capital for good ideas and teams with raw talent, and deep, hands-on, “every day” mentorship and talent development. Sharing R&D and software tools and platforms just adds to the power of the model.

For example, imagine that you wanted to hire a senior, CTO-level person to help develop more junior software developers. In virtually any startup in Africa, hiring someone with deep experience might prove too expensive (and equity models aren’t yet mature enough with a solid path to exit to attract talent in numbers). However, what if you could hire one CTO who worked across 4-5 startups and amortize that expense? The CTO would provide technical expertise on a day to day basis, but more importantly would engage in deep development (more than just a bi-weekly 1×1) of the technical staff and future CTOs of each of those companies.

It’s a highly leveraged model, and the goal would be to create a talent pool both within startups in the incubator and to create an outflow of talent as some technical staff inevitably go out to other companies or to their own startups.

Scenario E: Mifos App Network

Scenario E is 100% about taking Mifos into a mobile-enabled future, creating a network – connected, social, and mobile – that empowers the poor, delivering a range of services through apps, building for the future (Android, data access ubiquity), and aggregating apps in a network for the poor. To do this, we’d transform Mifos into a fully “mobile-ified” platform. Platforms alone aren’t enough, though, as very few platforms have impact or get to scale by themselves. Instead, apps beget platforms and we’ll need to build the killer apps that pull people and organizations to the platform.

The focus area for these apps, initially, would likely be new microfinance models that are both heavily mobile-centric and looking at going beyond traditional microfinance (Nuru and Musoni, for example). We want to go where the puck is going to be, betting on the mobile revolution and increased data connectivity across Africa and plugging into the huge momentum around mobile apps in East Africa.

That momentum – lots of mobile companies starting up – is great, and I think that we can augment the momentum with a strong back-end platform that aggregates and analyzes data and makes a wide variety of apps available to people in a relatively streamlined way.

Scenario D’

Both Scenario D and Scenario E are pretty complex, and complex is never a great way to start a new organization. The idea now is to combine them into Scenario D’, taking the basic model of Scenario D but starting with just one single company, getting that running, and seeing how the model works.

We would do this by creating a company that mobile-enables Mifos – either through the existing codebase or by contributing to a major rewrite – and makes Mifos the best microfinance platform in the world to deliver mobile services (financial and beyond) to the poor. Through this company, we’d also begin the talent development process and learn first hand what it takes to attract, develop, and retain world class software talent.

This scenario itself is still fairly complex and vague. For now I’m focused on the Ghana scenario, but next month from Nairobi I’ll be working to build out this scenario to a full-blown business plan as well.

* The five different scenarios were:

• A: Institute for Open Source & Software Entrepreneurship
• B: CloudLab Africa
• C: Y-Combinator for Africa
• D: MPOWER-based Incubator
• E: Mifos App Network

Let’s start with the talent gap, though. There are plenty of raw recruits out in the market, coming out of universities and other training programs with a reasonable set of web development skills (PHP, HTML, etc.). Those skills tend to be fairly shallow, though, and haven’t been honed or augmented with real-world experience. On the other side of the equation, there’s plenty of demand for software developers… but most companies need developers who have built real products, not just learned how to code in school, and those same companies tend not to have the resources to invest in the high-touch mentoring that’s needed to get a raw recruit to a developer who is ready to dive into an existing software company.

There are also plenty of people out trying to build software companies on their own – Bridgette’s seen them all across the continent – but those entrepreneurs tend to run into two challenges. First, they have no experience in shipping software. They can build software, but it often ends up as an unfinished product that can’t be taken to market; maybe they get 80% of the way there and stop, or run into an insurmountable problem, or whatever. Second, many entrepreneurs lack a deep understanding of viable software business models. Mobile app developers, for example, might want to just ship an app and start getting paid rather than looking at freemium or ad-supported models.

Part of the challenge, too, is that what constitutes a “viable software business model” in Africa is likely to be very different here than in the US, Europe, or Asia. Desktop computer usage is extremely low, and instead the communications vehicle of choice is a mobile phone. Most of those phones are feature phones (as opposed to smart phones), and companies like Google are doing some great work to make the internet more accessible on feature phones but it’s a much more fragmented environment than anywhere else I’ve been, and usage patterns look nothing like they do in the rest of the world.

I saw the beginnings of a vibrant community around software development in Nairobi, particularly around iHub and m:lab, and Bridgette said that there are many others around Africa working on solving what is a very hard and complex problem. There may be opportunities – some are in discussion – to bring the various actors together in a more structured way. Getting investors into the equation here is key, especially investors interested in providing seed stage capital to promising startups.

Potential solutions

The scenarios I’m working on in both Ghana and Kenya have the potential to contribute to some of these challenges. No single organization is going to solve all of the challenges, but I had a couple of takeaways after yesterday’s meeting.

First, one of the challenges in mentorship and building strong entrepreneurs is that taking a fresh graduate and dropping them straight into a startup environment isn’t the best way to teach them how to build finished products and business models. Mentoring from industry leaders is great, but it often comes once every few weeks at best. With a Mifos organization that is functioning partly as a working software company and partly as a software talent incubator, we can fill a few gaps. We can give young developers something manageable to work on – a feature, or an API – rather than expecting them to learn everything all at once. We can also engage them in teams of more experienced developers to learn what it means to work as part of a software team and to learn first-hand from more experienced developers in a deeply engaged, high touch way.

Second, we can explore gradually getting broader experience for these developers by giving them freelance opportunities with other companies. Many software companies in Africa need help on a short-term basis (“get me a J2ME coder, stat!”) and we may be able to build some sustainability into the model by contracting out the developers learning within the organization and giving them some sort of revenue share arrangement.

Many thanks to Bridgette Sexton at Google for her insights and passion around building stronger developer communities in Africa. The above ideas blend a lot of what I heard from Bridgette with some of the ideas we’re exploring for Mifos in Africa.

It turns out that this is great. OK, it’s mostly not great and is slowing down some of the work I need to be doing, but there’s one big advantage. I don’t check email compulsively when it’s slow and little on my phone. I look periodically, and defer handling most emails until a TBD time in the future when I have full connectivity again. Looking periodically – like once or twice a day – and deferring most email to batch process at a future time is probably one of the biggest productivity boosters for me.

Email is inherently asynchronous, but I think many of us (myself included) have gotten into the habit of treating it like a real-time life support feed. Every time I look at email, I’m not present and focused on the thing in front of me (whether that’s researching a new company, writing up a strategy idea, meeting with someone interesting, or chilling out and listening to music). Instead, I’m thinking about what might be – pretty much the direct opposite of being present with what is – and usually being unintentional about it.

I’m getting much better about this even when I do have connectivity, but it’s nice to have a little reminder every now and then that teaches me a) that the world doesn’t end when I’m not checking email and b) that I get more done better when email is turned off. My eventual goal is to get down to checking email once a day (or less), but for now I’m working on a routine that has me checking twice a day. We’ll see how that goes. (another contradictory lesson learned: get a flippin’ USB modem for backup, which I am doing tomorrow morning)

For the IOSSE in Accra, the primary goals will be:

• Work as part of the global Mifos community to foster further software development and innovation in Mifos and to work closely with Mifos specialists and MFIs in sub-Saharan Africa to maximize the positive impact of Mifos for the poor
• Work as part of the local software community to develop and nurture software entrepreneurs in Africa
• Support the development and impact of open source software in Africa

The core idea is to build a small organization that is actively working with real customers, initially focused on Mifos but later expanding to other open source projects, and that partners with local organizations (such as Ashesi University and MEST) to provide opportunities for local software entrepreneurs to gain real-world experience, learn from more experienced software developers and entrepreneurs, and contribute to open source projects that have an impact in Africa.

Depending on what happens with the global Mifos community (for example, will a global independent organization be created to continue to foster Mifos worldwide?), the IOSSE could play either a leadership or a contributing role to the oversight of Mifos. Our primary objective will be to advance Mifos’ impact in Africa, but doing that effectively will require a strong global community.

In the local Ghana software community, the idea would be for the IOSSE to work actively with other organizations like Ashesi, MEST, Google, and others who are working on strengthening the software community and industry in Ghana. I think that this will take a lot of collaboration across entities. It may involve creation of an iHub-like environment in Ghana (perhaps hosted at IOSSE?), or may take a different direction (less co-working space, more mentorship?). I’ve heard that conferences are very popular here in Ghana, but often end up with the same topics and speakers time after time. I haven’t spent enough time here to know what the right things are to create in order for the software entrepreneur environment to improve, but I imagine there are people working and living here who do.

The IOSSE organization itself would likely be quite small:

• A handful (3-5?) of developers, including at least one senior developer/architect and one with strong QA experience
• A product manager doubling as the Mifos community liaison
• A business/sales person who focuses on both partnerships with Mifos Specialists and direct MFI customer work
• A managing director or equivalent – although in this small an organization, that person may double up on the business/sales side
• Depending on how the organizations activities shake out – for example, will the org do cloud hosting or direct customer implementations and support – we may need to add support/services staff and sysadmin types

With that staffing level, and an initial focus on Mifos, the org could contribute to ongoing software development of Mifos (primarily around features relevant to African MFIs) and (hopefully) further the adoption of Mifos in Africa through both Mifos Specialists and direct MFI relationships.

From an overall talent development perspective, IOSSE could offer mentorship to emerging local software entrepreneurs and exposure to real-world software development and entrepreneurship practices. For example, by exposing software entrepreneurs to what it means to ship production software or to develop a customer-centric product roadmap and customer development process, IOSSE could augment raw business and coding talent with the skills needed to make a successful software company.

Beyond that, IOSSE might work with local educational organizations to develop co-delivered courses that bridge the gap between purely academic computer science courses and on-the-job experience. One idea that Patrick Awuah at Ashesi and I have brainstormed is the creation of an “Applications” course that would include both business and computer science students and pair them – one-on-one – with counterparts in IOSSE who are working on Mifos features, marketing, implementations, or whatever. The course would provide conceptual instruction on practical software entrepreneurship topics, and the 1×1 work with mentors at IOSSE would put that learning to immediate work and provide field experience to students.

Over time, IOSSE would look to branch out to other open source projects that are relevant and active in Africa (perhaps RapidSMS?). The IOSSE team will need to evaluate those opportunities once the organization is reasonably well established and has its first project – Mifos – well in hand.

There’s a lot more to learn, challenges to overcome, and big questions to answer before this can get off the ground:

• Can we find the talent to build the organization? This is probably the biggest challenge faced by everyone in Ghana. For IOSSE, having strong software architecture skills and experience in-house is critical to both the Mifos goals and to talent development overall.
• What are the local market needs for MFIs who might be using Mifos?
• How could IOSSE contribute to the local software entrepreneur community most effectively?
• Will the global Mifos community thrive independent of Grameen Foundation?
• Can this be done in a cost-effective way? Can it become financially sustainable over time, and is that important?
• The goals need to be refined and focused. Is this primarily a center for entrepreneurship, about advancing specific OSS projects, or spawning software companies?

The business plan itself needs a lot of work, and I’ll be focusing on that in the next couple of weeks to understand more specifically what the IOSSE would do, the resources needed, and what we’d have to get right to make it work effectively.

What am I missing? Can you help me make this stronger?

Ultimately, though, building a strong software industry in Africa requires strong talent – both technical and business oriented – that can found and scale African companies that solve hard problems with great software. My initial glimpses into the software talent pool in Africa have turned up a few things:

• Senior software talent – architects, senior developers, product managers, and the like – are vanishingly scarce in Ghana, Uganda, and Kenya (the three markets I’ve investigated)
• There are plenty of young, energetic, and talented developers around but they rarely have deep experience in building and shipping software
• Many of the most talented and experienced developers go for job security and good pay, and are locked up by banks and telcos (and are very hard to pry out of those jobs)
• There are lots of incubators around, especially around East Africa, giving entrepreneurs a place to go and find community and in some cases find mentorship, learn at events, etc.

What I’m not seeing – and hearing a need for – is deep, structured mentoring that builds skills and experience through daily contact with people who have built companies and products before and learned some of the tools and methodologies. It looks like some of the incubators – m:lab east africa, for example – are trying out some new approaches to tackle this problem, and I’m looking forward to learning more about how that works.

There are a couple of US-based models that have caught my eye as well:

• The well-known Y Combinator approach combines seed funding (usually under $20,000 USD) with help that ranges from what to build, how to build it, and making deals with investors and/or acquirers. They help startups get incorporated properly and host investor days, dinners with speakers, and perhaps most importantly have a rich and active alumni community.
• I’ve just run across MPOWER, and I’m finding their model super interesting. It’s high overhead (I’m guessing – need to talk to them to validate) but seems like a great model to think about replicating in Africa to augment the vibrant incubator community. Basically, MPOWER Ventures is a VC that focuses on empowering underserved populations. Their first portfolio company is MPOWER Labs, a combo of a shared R&D facility, shared company infrastructure, and a bunch of talented people who can work with multiple portfolio companies on both business and technology problems

The thing that I like – a lot – about the MPOWER model is that it brings together deep talent (often expensive) and amortizes that talent across a bunch of companies to reduce the cost profile for any given startup. I could see this working really well in Africa – imagine matching up an experienced CTO who has great architecture chops and a great product manager who knows how to ship software (not the same as writing code!) with 4-5 startups with great local product ideas, coding chops, and energy/passion for what they’re trying to build.

The other idea I’m toying with is creating a single company – probably focused on Mifos – that partners with one or more universities to give CS students exposure to real world software development and software companies. For example, you could imagine an “Applications” course that is a hybrid of coursework and quasi-internship and brings together both CS and business students, pairing them with their counterparts inside the company. Maybe it’s worth the equivalent credits of two courses (to ensure that students have the time/energy to dedicate to the work) and includes academic lectures, studio sessions with team from the company, and real-world work experience. A CS student might pair up with a senior developer to work on a new API; a business student might work on the launch plan for a new version of the software.

The underlying idea is to move toward much deeper mentorship, coaching, training, education in a real world working context, pairing inexperienced but smart talent with deeply experienced people who are working on building a real business and can help show their charges how what they learned in school changes when it gets into the real world. Building a successful company takes much more than just writing code and putting it in customers’ hands – it requires understanding customers, testing hypotheses, driving a release plan, setting up support tools and infrastructure, etc., and a lot of the entrepreneurs I’m coming across in Africa have great ideas but no exposure to what it takes to turn those ideas into successful product companies… and, unfortunately, nowhere to turn to get a leg up on learning those skills and methodologies.

Ben at Kopo Kopo blogged recently that

Africa is rising. The continent’s 1B+ people are largely young, urban, tech savvy, and brand / status conscious. Pockets of the continent – Accra, Cairo, Lagos, Nairobi, etc. – are globally-connected. They read Mashable and New York Times. They demand accountability and transparency. And they are the future.

I think that’s absolutely right… there are massive opportunities for software firms in Africa, and jumpstarting deeper development and nurturing of talent is one of the critical factors to attracting investment and simply to enabling some of the great ideas that African entrepreneurs have to take root and blossom.

Consider a network – connected, social, and mobile – that delivers services to empower the poor in Africa. The services could range from traditional microfinance services (credit, savings, insurance) to health and ag information to pure P2P lending services built on a mobile payments platform.

The underlying premises of such a network would be:

• Find hard problems that the poor face every day and deliver access to apps that solve those problems
• Make assumptions about a future state – $25 Android phones and ubiquitous data access, for example – but build in an inclusive way that leverages today’s prevalence of feature phones (using SMS/USSD)
• Engage the broader community across Africa – app providers, MFIs, etc. – in the creation of a connected marketplace for the poor

In doing this, can we remove friction and costs from the flow of both information and capital to and from the poor?

I’ve talked to a couple of MFIs (and MFI-like) organizations here who are starting to go in this direction. Musoni (a Dutch-based MFI with operations in Kenya) is providing traditional microfinance services but are 100% built on the M-Pesa platform. By leveraging the mobile platform 100%, they have the opportunity to build additional value-added services to deliver to their clients over time. Nuru International, based in the US with operations in Kenya, is a development organization with multiple areas of focus ranging from economic development to agriculture to water & sanitation. They’re using Mifos today for their microfinance programs, but could really use a platform that enables them to see what’s happening across all of their programs and to push both information and capital (and proxies for capital, like seed and fertilizer) to their clients.

If so, what are the technology requirements to make something like this work? At it’s core, this is about creation of a platform that has these attributes:

• Flexible and extensible: supports many models for the delivery of microfinance services, and includes the interface points to plug in new apps at a low time/energy/financial cost
• Aggregates information across apps: see what’s happening in the ecosystem and provide information to both users and service providers
• General purpose: can be leveraged for any kind of information or capital transaction

Rather than focusing future Mifos development on incremental features for traditional microfinance services, maybe the real play is to leapfrog to a network of apps – including those that support traditional microfinance – to empower MFIs to grow both in scale and breadth of services, leveraging the explosion of mobile access and mobile apps across Africa.

This is clearly a very high-level, abstract, and early-stage idea but I think that there’s a lot of potential in this and invite others to help refine and improve the idea.