Last month while I was visiting Ashesi University in Ghana, I met with a few students (two in CS, and one in the MIS program) and talked to them about what they want to build when they leave Ashesi and what they see as their biggest future challenges. One of the CS majors talked about wanting to build a software company, and how he saw his biggest challenge as getting customers to use the software and apps that he builds.

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.

Great summary of the Pivot25 conference from Nairobi last week by an investor from Tanzania / Silicon Valley. This chunk (near the end) resonated particularly strongly for me:

Technology is not often enough: There needs to be increasing focus on companies adopting lean customer development methodologies and spending more time talking to their target customers. The term “Pivot” is widely used in Silicon Valley to describe a change in direction after new insights after putting out a product to market. Many of the East African entrepreneurs pitching didn’t show signs of this, nor did the panels believe enough in teams to adjust, questions like “what are you doing to compete with foursquare?” often ignored the very nature of the team’s willingness to adapt and differentiate- at least that should have been the response of startups asking questions like this. Investors bet on teams and execution, not ideas. One investor even mentioned that ideas alone have a negative Return on Investment (for taking up valuable time of the investor without showing any progress).”

This is extremely true and exactly where the focus needs to land for the African software/tech entrepreneur community. The participants at Pivot25 had wildly varying degrees of energy, great ideas, and sound technology – some stood out as very viable companies while others seemed destined for the dustbin – but the common theme that I saw was a need for serious mentoring on how to build a successful software company. This ranges from lean startup and customer development process ideas and tools to the basics of how to ship software effectively (which is way more than just writing code). Culture is important too – specifically, building a culture of trying, failing, iterating, and following the best idea. The Core Protocols would be nice to add to the mix.

There are many incubators in place or in the works in Nairobi, and I’m investigating which ones (like mLab and iHub) are going to be able to provide that deep hands on coaching. Maybe an accelerator is needed (a la Y Combinator), or maybe a holding company / investment fund that goes 10-100X beyond the usual degree of mentoring and coaching?

So I’m holed up at home this weekend, trying to crank out (finally) a draft business plan for Mifos. It’s hard – harder than I thought it would be, but easier than it probably should be. If nothing else, it’s a great exercise for getting clarity into what we’ve got clarity on, and what we don’t. For example, we seem to need more work on a pricing strategy. Correction: we seem to need a pricing strategy.

It’s a gorgeous weekend in Seattle, and while it would be nice to be outside enjoying the near-summer conditions, this is one of the two really important things in my life at the moment (the other is our upcoming wedding, which is approaching faster than I could have imagined). And so, on I slog. Here’s hoping that my Memorial Day output yields the ROI I’m looking for…

Interesting factoid:

  • MySQL was bought by Sun for $1 billion
  • Burt’s Bees was bought by Clorox for $913 million

In other words, the two companies were purchased for more or less the same amounts. I’m not sure yet what that really means, if anything, other than that lip balm might be as good a business to get into as open source enterprise software.

© 2011 On Safari with Oldupai George Suffusion theme by Sayontan Sinha (modified)