In South Africa, we're doing things a bit differently than previous GSL programs. I want to make this as explicit as I can, so that no matter our outcome, we will have learned something about the process of creating an entrepreneur ecosystem in Johannesburg.
The first major difference between our curriculum and those of the past is our heavy emphasis on customer development from day one. There are some assumptions that motivate this choice (and lots of wisdom in the field which supports them). The first assumption is that when you're good at building (as engineers are) it's easy to accidentally build something that nobody wants. It's just too tempting to start building too early. Sometimes it's easier to build a app that uses bluetooth to transfer business card information to someone else with the same app than it is to conduct enough quality interviews with prospective customers to realize that, although nice, exchanging a physical business card isn't so inconvenient that they would pay for an easier alternative, for example.
Why does this happen? Why are people so eager to get building and so shy about talking to people and learning what problems they care enough about that they are willing to pay to have them solved?
I'll offer two models that help us understand why we'd expect this behavior from engineers without any customer development experience, which I draw from the work of Mihaly Csikszentmihalyi, the prominent positive psychologist.
Difficulty versus skill level: staying in the sweet spot.
Basically, people have an aversion to both boredom and stress. Boredom happens when the skill level of the individual vastly exceeds the difficulty of the task at hand. On the flip-side, stress happens when the difficulty vastly exceeds the skill for the task. The effortless retainment of a person's engagement and focus for a task requires that the difficulty and skill stay balanced as closely as possible, perhaps with a slight elevation of difficulty over the skill. This way things are challenging but not discouragingly so.
Doing customer development work is no exception. If I ask a brilliant software engineer to call up the CEOs from the top 5 real-estate firms in the country with little more instruction than to find out about the problems in their industry, I might as well have just kicked him into a buzz saw.
After only a few times of getting hung up on or stumbling through an awkward conversation these guys aren't going to persevere. It doesn't matter how smart and competent they are in other domains. People avoid stress and run from pain. Those who do persevere are definitely unicorns, which is not a realistic thing to expect of many people who otherwise have high potential for becoming successful entrepreneurs. It's too stressful to tackle problems so difficult for you that you see no positive feedback, and it's natural to expect people faced with such problems to extricate themselves from all but the most clear life-or-death situations.
Our emphasis on customer development bares all this in mind. We expect than many of our founders will not have had an extensive background in sales or market research, and so the first days of the program we have organized things such that they can get as much practice as possible on relevant customer development work that is within reach of their skill level. In doing this, we maximize the number of engineers we can convert into those highly sought after "unicorns": those people who can hustle, code and know what to code, all at the same time.
Another model that we use to design our curriculum and organize our program comes from a related set of concepts, but is more specifically geared towards keeping people in a state of flow for as long as possible. Flow is that state of optimal experience—a feeling of engagement so strong that everything else drops away, you become indifferent to how well you are doing, and time passes without you realizing it. There are about 8 elements to achieving this consistently, but the most important are 1) having a clear set of goals, 2) having immediate feedback, and 3) balancing the difficulty of the task with your skill for doing it (as described above). Having clear goals lets you keep your attention on what matters when things start to get too complicated and difficult. Having immediate feedback allows you to quickly adjust your strategy when things aren't working (and let's you know that your strategy has stopped working in the first place). And balancing skill and difficult prevents you from getting bored or too stressed.
A big challenge from most budding entrepreneurs with a technical background is finding what problems other people have that they are willing to pay to have solved for them. Engineers usually understand well the problems that other engineers have, but solutions for problems unique to software engineers that are solvable with software don't usually last long because they themselves have the tools and skills to solve them, just as most blacksmiths have exactly the hammer and anvil they most need.
Because of all this, software engineers who want to start their own ventures with very little capital usually need to find the low-hanging fruit from other domains where software solutions aren't pervasive but would be valued. Unless you are clairvoyant, this requires talking to people. This requires extensive customer development. And this is exactly what we're sprinting towards from day one.
The second way our program differs from the others is how we introduce new material. In the beginning we're doing ONLY customer development. Any tech we teach is entirely to better serve the process of customer development. Done right, this doesn't usually require writing a single line of code, but there are some web apps that make things a lot easier. Whois and rapportive, just to name a few.
The reason we're doing that is because we believe that it's just not productive to introduce too many new ideas at the same time—and many of the ideas in customer development are going to be more new to technical people than most anything else. Additionally, by completely eliminating any tech curriculum in the first two weeks of the program, we are also eliminating the temptation to procrastinate this difficult and strange new work by offering something that the founders are better at and would probably rather do. Only once they know exactly what they need to build will we allow them to start building. Almost certainly their product will continue to evolve even after they are sure of what they need to build, but the problem they need to solve is likely on pretty solid ground, and this is the most important thing. And once people have a pretty good idea of the exact problem and that people will pay them to solve it, only then do we turn on the after-burners, and sprint to shipping prototypes and MVPs.
I believe this is going to produce a categorically higher rate of learning for our founders. I could be wrong. But as I've outlined the reasons for our divergence here, no matter the outcome, we're going to learn something.