South Africa Summer 2014 Blog

University of the Witwatersrand
June 23, 2014 to Aug. 2, 2014

Conversations with Wine makers

Emele S Uka

June 27, 2014

Going along with our theme of customer developement the founders called multiple leads to better understand their problem space. Below is an excerpt from Dean Hirst.



Conversations with Wine makers

I decided to work in the field of viticulture, and find out if there are any gaps to fill with technology in the production process of wine making. As it turns out, there are plenty.


I called the front desk and asked to speak to the cellarmaster, Stephan, who was more than happy to chat to me about the applications of technology in viticulture. After a broad question about the most labour intensive exercise in the wine-making process, Stephan really opened up, I felt that it was appropriate to ask him as much as I wanted to, with no need to awkwardly cut the call short, or skip any questions I had planned.


The first main question I asked Stephan was “what strengths do you have has a brand/product that you can work on to achieve greater success? ” His answer detailed the need for large amounts of capital if you wish to produce large volumes of wine, and that having an existing brand, and facilities, enables a wine farm to outperform new comers to the Champagne and wine market.


The question that gained me the most insight was “what simple tasks do you have to do on a regular basis to succeed as a brand, and a business, that could be done by technology”


At this point Stephan began to speak about things I hadn’t heard of before, which was a good sign. He spoke about gyro-pallets and labelling, and that the two could become one synced process. WHich really peaked my interests. I have no idea what is involved in either one of those processes, but I intend to focus my research in that area, and re-assess my call and email scripts, to focus more on this area.


Great day.


Two ways we're doing things differently than other GSL programs and why...

Bryan Hernandez

June 26, 2014

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.

So you have a good idea...

Bryan Hernandez

June 25, 2014

What is that spark that makes ideas so seductive?  Where does it come from?  To what examples should we look as the source for this common misconception?

It's not about the idea.

It's said again and again, over and over, but still even the most disciplined entrepreneurs fall victim sometimes to the excitement and over-enthusiasm of a good idea that they're just certain will work. 

These are the characteristics of a visionary.  The attitudes of philosophers and scientists.  And they are highly admirable and respectable attributes to have.  But they are seductive, too.  And as many seductive things are, they lead not always in the direction we know deep down we must go.

This letter is to the scientists, philosophers, dreamers and visionaries among us.  Those who got into this game because of the things it ought to be—not what it is.  That you have decided to learn about the practical side of business economics and startup creation is an encouraging sign not only for our class of men and women but for the future of our civilation at large.

But let me remind you of something you already know.  It's not about the idea.  It's about the result.  Distrust yourself.  Distrust your idea.  Seek learning not proofs on paper.  Look to disprove more rigorously your own hypotheses about what it is the world now needs most than you would try to disprove me had I just told you that there really is NO more in heaven and earth than is dreamt of in your philosophy.


Why we go for sales first

Bryan Hernandez

June 17, 2014

In any skill or knowledge transfer, there is a tendency to start teaching the topics that you know or understand the best. This often makes for a smoother teaching and learning experience. The instructor feels at ease and confident in his comfort zone, and the student benefits from being skillfully eased into a new domain with the masterful guidance of someone who clearly knows what he's talking about backwards and forwards.


This is fantastic, but not always the right thing to do.


In entrepreneurship, the thing you most need to be doing is probably not the thing you feel the best at. It's probably not sitting down and optimizing that block of code, or fine-tuning the hue of your logo background. Coming from an engineering background, this can be especially difficult. An engineer is a creature who is especially good at solving a certain set of technical problems. Working on those kinds of problems is especially pleasurable when you're good at solving them. However, in entrepreneurship this can be dangerous because of the tendency of that tech-derived pleasure to draw away your attention and energy from other less familiar but more important kinds of problems.

How many startups failed because they flawlessly solved a problem or built a product that nobody cared about? I can definitely count myself in that bunch, just as can many other entrepreneurs who eventually went on to realize the mistake and ultimately become very successful.

There are some useful models that explain why we might expect this behavior—especially from highly competent technical people—but I don't need to get into that just now. My major point is that most startups made up of technical people will not fail for technical reasons. They will fail because they will not address the critical problems a startup needs to solve—the problems that technical people usually have are least experienced with or generally don't like.


This is why we're going after the first Rand.


Everybody knows that the necessary and sufficient condition for a viable business is a paying customer. So let's make sure we can get that before doing anymore work at all. The value of all work done without some kind of confidence that there are paying customers waiting for you at the finish line is a complete gamble. And startups don't have a lot of resources to gamble. If at all possible, we want to minimize this kind of work. Startups are severly resource limited, and so we cannot spend our time and money frivilously.

There is an added psychological bonus to this milestone as well. Seeing that people will actually give you their money if you solve a problem they care about is a life-changing experience. It suppresses much of the self-doubt many people have when getting started as entrepreneurs, which in the beginning is a very important thing to avoid.

I want to shatter our founders' conception for the steps required to launch a vaible business.

From day one, we push hard on customer development and getting the first customer commitment. Not uncommonly, this can be done before writing a single line of code! Again, the challenge with this approach is preventing the engineers on the team from running wild on what they believe to be the correct solution to the problem at its first sign, and instead use that Grade-A engineering discipline to stay focused on validating the customer and market.

Let's have the excitement of waiting customers be what drives you to a build your app. Let's not have the sunk cost of having already built a product be the driver to find someone who is willing to pay for it.