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.