Startups are Hard
Personalised software development with the agility of a small team, and all the experience of delivering world class solutions.
software, software development, software dev, software engineering, app development, app dev, apps, apple app, android app, mobile app, internet of things, iot, IoT, re:source design, resource design, resource, re:source, re-source design, re-source, rse, software development south africa, software development sa, software development joburg, software development jhb, software development johannesburg, software dev south africa, software dev sa, software dev joburg, software dev jhb, software dev johannesburg
686
post-template-default,single,single-post,postid-686,single-format-standard,bridge-core-1.0.6,ajax_fade,page_not_loaded,,qode_grid_1300,qode-content-sidebar-responsive,qode-theme-ver-18.2,qode-theme-bridge,disabled_footer_bottom,wpb-js-composer js-comp-ver-6.0.5,vc_responsive

Startups are Hard

Startups are Hard

Especially in South Africa.

That’s why I will be writing a series of posts to discuss some of the most common challenges you will face while building your startup business.

The following concepts can help bring success in many industries beyond tech. But we’ll keep the focus on tech startups, software platforms and apps. The South African context means you need to consider factors that don’t exist in other markets. Most of the population here don’t have large disposable incomes. Furthermore, people often must pay exorbitant fees for services that should come from the government or municipalities.

So you have a great idea?

Startup Ideas, building your own startup in Johannesburg South Africa

Launching your startup can prove tricky, especially in South Africa. Perhaps that’s why nearly every day entrepreneurs come to re:source design for help with their tech ideas. These range from simple solutions to grand plans for competing with Google and Facebook. Here, we always try to find ways to make an idea work rather than picking holes in it. Because you never know if something brilliant could come out of it. Also, we believe a world with people dreaming big is a far better place.

That said, if we had a bitcoin for every time someone came to us wanting to add an app chat or insert a random feature that most users don’t need, or talking about achieving social media integration, we could be very rich. These features can be great and can always be added later. But, initially, if they are not a core part of your solution, they add a lot of time, complexity and cost. This hinders you from progressing through the development cycle to the best product or market fit.

Don’t be too attached to your solution.

Rethinking potential solutions speedily while getting early feedback is key to building a solution people want. The final result could look very different to the solution you envisioned initially. We’ve seen founders so attached to their solution that they believe it’s the user’s behaviour that should change rather than the solution. This usually proves a slow and agonising path to failure but can be easily avoided by considering usage data or user feedback. True, it’s not wise to listen to every user suggestion or try to solve every user need. But it’s usually advantageous to study usage trends and statistics to identify where bottlenecks or drop-offs occur. 

The next post will discuss how to plan a Minimum Viable Product (MVP) that provides meaningful feedback to validate your idea and help you build what people want.

Many factors will influence things along the way. Luck is crucial. Any successful startup or entrepreneur who denies that luck, fate, providence, or whatever you want to call it, played some role in their success, is probably not being honest. Unfortunately, there isn’t a reliable way to influence luck. But you can control many other factors that will best place you to take advantage of luck if it comes along. Start by deciding which concept or idea to work on.

Start with a problem.

At re:source design we see many startups try to figure out what “solutions” they can build using new technology, such as VR, AR, iBeacons, Blockchain, etc. Or they identify a successful business model in one industry, and try copy and paste it into another, like an “Uber for X”. While both approaches can lead to success, we have found they usually aren’t reliable routes to creating a successful product.

One of the best ways to discover a good concept, is to start by solving a problem. Preferably a problem many people experience—regularly—but without an affordable or reliable way to solve. If you can find and solve a problem that meets those criteria there is a far greater chance your solution will have the elusive product/market fit that is instrumental in so many startup successes. For more detail and a great talk on product/market fit, this video by Michael Siebel is required viewing.

“Talent hits a target no one else can hit; Genius hits a target no one else can see.”

– Arthur Schopenhauer

You could argue startups like WhatsApp or Facebook—or perhaps Myspace before that—didn’t really solve problems, because before their existence people never had reliable mobile text messaging or social networks. So, there were no related ‘problems’ that needed solving. But there were more fundamental challenges, such as the need for synchronisation to communicate effectively with each other in an increasingly fast paced society. The genius of startups like FaceBook was overcoming these hurdles in a new or better way. That leads us to the next part of the concept development.

In South Africa there are many problems that don’t exist in first world countries. This can be turned into an advantage. Sometimes a low-cost solution developed here can have massive potential in a first world country, because no one there bothered to consider an alternative solution.

Build Something People Want.

alt text goes here

Once you identify a problem worth solving, you must consider the solution to build. Here the potential pitfall is building something you think people want, or something you might want, rather than something the majority of people want. For a great video on this by Kevin Hale watch this

Often at re:source we’re approached by clients who deliver a 50- to 100-page requirements-specification document describing their solution. The first potential issue here is if the client has designed a solution without doing any real evaluating or testing to establish if users would actually use that solution. The second potential issue is if they have equated “better” with squeezing all the possible features they can think of into the solution.

“More features make your product worse, not better”

– re:source design

A key phrase we use at re:source when discussing a new concept is “More features make your product worse, not better”. The reasons: feature bloat means it takes much longer to build and test whether or not your solution solves the initial problem; also, presenting a user with too much functionality at the beginning risks them becoming overwhelmed and then not using the app at all.