The following are some principles essential for the success of any venture. They are commonsensical, but perhaps counter-intuitive.

Solve sombody’s problem!

Do you hear people complaining? Music to my hears. They are giving away their problems, for free. This affords an opportunity. For example, some common problems:

• Cheap packaging that won’t ruin the environment if incorrectly discarded (cf: plastics).
• Cheap and reliable energy sources.
• Cheap, reliable and fast transportation.
• An easy solution to drought.
• An easy solution to political incompetence and economic mismanagement.
• An easy solution to cancer, disease, obesity, relationship problems.

Your job is to come up with a solution.

To simplify: (i) identify a problem, and (ii) solve it. This is very different to the notion of making the world a better place: forcing people to do the right thing or punishing people for doing the wrong thing, applied within the edifice of a business.

• requiring people by fiat to switch to renewable energy sources, or
• educating people on the benefits of taking care of your health.

All noble pursuits, but they sound more like social movements, rather than business ventures.

If you’re not solving a problem, or if it’s a problem that no one thinks that they have (even though they do) then you’re not going to get very far.

Example: Building a useless product: I started writing some software to solve a common problem - at least in the way that I thought it should be solved. But I was not the end user. The end user was different. I thought I could infer their problems and requirements without actually talking to them - and they had no interest in talking to me - which is a different problem altogether. All in all, I must have spent about 3 months writing it, with the backing of management. On delivery, the team that was supposed to use it, did not use it. Why? Because it was not conducive to their particular workflow, they did not really understand how to use the software (and were not bothered to learn), and lastly, they had no interest or incentive to use that piece of software or to drive its development. They have their own vested interests, which were slightly different to the interests of the business they were working for, and to the interests of management. Their existing solutions were bareable enough. Having said that, a similar iteration of that same piece of software was given a different team, within the same organisation, - is being amply used!

Did you catch that? Don’t build a product without having a user actually USE your product. Users are all different, with different interests and incentives in mind, and different worflows.

Running After Investors

Your core focus should be on building your product. If focus your limited time on running after investors (rather than them flocking to you), then you’re starting behind the 8-ball. Ideally, you will be generating enough cash so that you will not need investors. And the irony is that investors always want to give money to someone who doesn’t need it.

Philosophy

Your philosophy and ethos dictates the way you should move forward.

(1) As far as possible, the person using your product, should be the ones paying for it.

If Freddie is using the product, and Brian is paying for it: they’re not playing in the same band. Brian will make demands that are not conducive to Freddie’s interests - that of the user. This creates perverse outcomes and incentives.

(2) Keep it straight and narrow

• Avoid doing anything illegal: e.g. bootlegging and the like. It won’t be as profitable or as easy in the short-run, but you’ll be forced to make decisions that will better preserve you in the long run.

What problems should I solve?

(a) People don’t know what they want.

This has been my experience: people generally don’t understand the benefit of something when you explain it to them. People don’t know what they want. They cannot explain something they cannot conceive. But once presented with a solution they can clearly understand, they may say: “Ah-ha! Yes!! I want that!”.

The process of taking someone from ignorance, to where they insist on having what you give them: that is artistry, that is creativity. There are few with the vision to see things described by an idea. Even when presented with a useful solution, many will outright reject it, because of their myopia, or preconceived ideas etc. You’ll have to connect the dots for them.

Case Study: I once presented a solution to a superior, which was self evident. We were bleeding money and I found a way to capture all of it. The response was one of indifference. If listened to that, then I would have never created anything that was useful. I persisted, and basically made a proto-type behind the superior’s back – and possibly against his wishes. I presented to the prototype to a luke warm reception. This was later scraped, and redesigned, and rereleased. The result? It was a resounding success. Which goes to show you: even amongst the most educated in an industry: they don’t know, and they don’t understand what will or will not work. The only way is to try things out, and to prove it empirically.

Case Study: If Henry Ford would have asked the market what they wanted, they would have responded: “Faster horses. Less jaded horses etc.”

Summary: The point is that you cannot always rely on the customer to tell you want they want, if they cannot conceive it. Neither should you rely on well-meaning friends and family. If you show your product to someone who needs it, they should immediately recognise it: “Yes! I want that!”

What are the problems people have?

Better, faster, cheaper

If you gave someone an IPhone 300 years ago, they probably wouldn’t understand its significance. “Very nice!” he might say, before tossing it over his shoulder. But if you let him realise that he could make money from it somehow - or could save money, or it would save him labour: that is something that he will immediately appreciate. People are myopic.

Unfortunately, progress is limited by the myopia of the population. You must educate them - in their language, and how they understand concepts, in order for them to realise the value and worth of your solution. Simply handing them an Iphone is not enough, or telling them about this new thing called the internet. You’re going to have to connect the dots for them.

You will be constrained by the limitations and mental faculties of a plebian population. You cannot expect the average Melbournian baby-boomer with 6 investment properties to understand the value of Git. But you certainly can expect them to understand a product/service which allows them to: borrow more money, at lower rates (preferably free), without having to repay anything: “I want that!” they may say.

Product/Service Ideas Abstracted

The vast majority of the human race, suffers from some combination of the following four malaises: (i) sloth, (ii) folly, (iii) mendacity, and lastly (iv) their stomach.

Or stated less sadronically, if you can find a way to make something: (i) easier / faster / better, (ii) that allows people to make better decisions, (iii) that reveals the truth of a matter clearly, or (iv) that satisfies primordial needs e.g. hunger (food, entertainment, attention etc.) then you have a product.

Generally, any tool you build, that allows for more work to be done with less time, or with less effort: is a good tool.

What ever problem you are trying to solve, if it attends to one or more of the above (which feeds the gluttonous appetite of the majority): you will have a winner. The men and women who solve these problems cannot be more diametrically opposed in character to those of our human condition suffering from the aforementioned mental aberrations.

If you can build a tool, that is universally useful, and that only you are skilled enough to make, or put together, then you will have a very desirable monopoly. The difficulty and efficiency by which you put together the said product or service, will be the moat which protects you from the onslaught of competition, which will surely come in time. Humans build these things, and other humans are capable of building them too. No kingdom or company lasts forever, unless it is dilligently stewarded. Mere humans are incapable of such tasks.

Another thing I have noticed: if you can build a useful tool, allowing for others to build ON TOP OF your tool - then your position will be more secure. All the users of the latter tools will be beholden to you; and given the nature of the human condition, once something is built, folks are less likely to move away from it, even when a more promising solution presents itself.

What ever you build it should be: (i) better, (ii) faster, and/or (iii) cheaper. Or it should allow for things to be done, better, faster or more cheaply.

The Human Being is your Client: set the expectation of the solution

Humans are fallible. They do stupid and inexplicable things. Sometimes dangerous:

**Some Examples**
e.g. McDonald's was famously sued because their coffee was too hot. (In actuality, the plaintiff had wisely chosen to keep a cup of boiling coffee right between her legs while driving (don't ask me why?). The car lurched and the results were predictable.

Another example:  was the guy who mistook "cruise control" for "self-driving" (this was before the concept of self-driving cars btw) so this guy was without the least excuse. So while driving on the freeway, he decided to leave the steering wheel and go to the back of the van to make himself a cup of coffee. The results in both cases were predictable. The point being is that the expectations of these people were erroneous.

Because we are dealing with human beings, the expectations must be set. The correct expectation must be set. But if you are trying to start a car, and the results are patchy: that might annoy the end user. The expectations have not been met.

Incentive

At the heart of everything said here is incentive and choice.

If you have a problem, it can be solved with the right incentives.

(1) Don’t hire unable / incompetent people

The hiring of unable persons is actively destructive (i.e. hiring in-laws who refuse work, are too proud to beg, but demand emolument). Correspondingly, the hiring of fit and capable people will redound an immeasurable benefit. The loss and benefit is doubled. Granted, you are not going to find Einsteins freely discarded on the street, but you will find people who show potential, and are immeasurably capable if given the encouragement and resources.

(2) Measure the Cost Beforehand (in so far as it is possible)

Count the cost before going to war. Would you go to war if you knew before hand that you would lose? In other words, measure the cost and benefits of a proposed course of action, as much as possible before hand. This is a nebulous undertaking. And if there are many unknowns associated with the estimation, then the best way of gaining more accurate information is to make a trial run of it by limiting the costs. Trial runs mitigate risks, and costs, while still allowing for the potential of the upside to be explored. The trick here is to appropriately stage the trials (with short-cuts every step of the way) and to see if you earn something from them.

(2) Try Before you Buy

Often times you fill find that things will fail when you try to do something: there will be unforseeable problems which may be uncovered. Why not undertake all of the above in a test situation prior to any dangerous and costly expenditures of building a full-featured solution? In a test situation, the costs are minimised - not so in the real life situation.

(3) Be Straight in Your Dealings

“I’ll pay you tomorrow”. If that’s the case make sure you do. If you don’t have the money then you will be forced to procure it, and that exercise will improve processes right away.

(4) Sell or Market what you have right now

If you have something, it might be worth trying to make something of what you have. Why not? It is better for it to be utilised than for it to simply sit there idly. Ideally, if you can sell it, then you can use the proceeds to make the product/service even better. That will surely redound greater profits.

(5) Don’t build things which aren’t really necessary

I feel that software, at its fundamental core, is an investment decision. Resources are limited: (i) time, (ii) knowledge, (iii) manpower and (iv) money all in the pursuit of a certain objective. If the former is finite then the latter cannot expand to infinity. It’s a common problem: you have three options, but must choose two: (1) speed/features, (2) quality and (3) budget. Or some variation of this. The only way you can have all three is to exercise some degree of creativity and/or improve productivity.

The dangerous trap which one may fall into, is to solve problems which are not really problems, and even worse, to spend the limited time and finite resources you have, running after those things. Of course, all of this is predicated on understanding the problem fundamentally itself………If you understand the problem, I mean truly understand it, then this is a victory, in and of itself.

To summarise: you need to identify the absolutely bare-bones features and the problem you are trying to solve, and to solve that. After that is solved, then you may have some limited scope to improve upon it with (basic features which are missing.) You do not want to be spending time adding features which are not going to yield you any returns.

(6) Skill and knowledge is a very rare gem

I’m telling you that this is the most problematic thing in the world. To find someone who really knows something, who is a skilled craftsperson - THAT is a very rare jewel. A efficient professional is worth a hundred inefficient ones. You can do a lot with one efficient person. Finding that person is the hard part. If you can find that person, then the chances that you will succeed will be more in your favour.

(7) Be ready to pivot

Nobody can pierce through the viel of the future and see all that is before them. Things will come to light as you progress on your journey. Exploit any opportunities which arise (be vigilant about this) and avoid the pitfalls as they come, or as you notice them. Clinging to a losing strategy, or a strategy that isn’t working, is a sure-fire path to failure. Change things up a bit, and you may have greater success.

One such example was General Grant (a Union civil war general): he wanted to cross the Mississippi at Grand Gulf, but he found that the batteries were too strong there. So he adapted: he was forced to. He decided to cross his army further down stream at Bruinsberg, after a slave told him about a potential landing site there. On investigation, he found that landing site to be suitable. Sure, it was not part of his original plan, and certainly, he was further down river than he would have liked, but he had to adapt. Or his army would disintegrate from a lack of morale, supplies, and political pressures from Washington.

(8) Start Small

This is probably the most important thing, that I have learned the hard way. Start small. Whatever it is. Try and make it as simple as possible. And when you have that working, then you are free to add layers of complexity to it.

(9) Build Something, and unforeseen benefits will be likely to follow

Nobody can see the future. But the following adage is true: ‘starting knitting and God will provide the wool’. If you create something that solves an existing problem, and if you keep your eyes open, new problems will almost certainly surface. Entire new worlds will open up. Solve those problems when they arise. But they key is, those problems will only arise if you build in the first place. Always keep the following in mind: “better, faster, cheaper”.

(10) Creative Solutions with limited resources

Mother is the necessity of all invention. If you don’t have the resources, you will have to craft your own, more efficient solutions, or elide those proposals entirely.

Example: In my own case, I’m an indie developer. I’m not a Procore with infinite amounts of venture capital backing me etc. I cannot afford to have ANY help desk calls. Therefore, everything I do MUST be super simple and easy, and idiot proof. Any opportunity for confusion is no good for my customers. Too many options - and they won’t be able to handle it. If I had cash to burn, then I would add complex options: the ability to have organiations and organisation admins, and all associated features could be built, and we could have entire call centres and management overseeing them to cater for those features - but I don’t have that luxury. So, the concept of having an “organisation” in my app MUST GO.

Embrace constraints. And derive creative solutions as a result.

Project Management

This forms a summary of ideas from Basecamp’s experiences, summed up in “Shape Up”. Warning: these are my interpretations of what is written in there + my own take on things.

(a) 6 week cycles

Everything must be done in 6 weeks. If it takes longer, then cut down the project, and scope, to its bare bones essentials so that a minimal version is done in 6 weeks. I suppose this is a good philosophy, because it limits the extent to which one invests in a project before seeing any positive returns.

(b) Shaping the work

Basecamp seems to suggest that a small senior group makes the key decisions, and after those decisions are made, a vague yet clearly defined scope is given to a secondary team to implement. This makes sense. Designing something by committee, in my experience, is rarely a good idea. One person must design it, and make the final decisions, but this person can be aided (and abetted) by a group of advisors, sharing different points of view, with widely varying backgrounds. And after the project is handed over, full responsibility is given over to them. I suppose that in my experience, if full responsibility is given, it must devolve upon one person to deliver. I’d want to avoid problems where decisions and responsbility falls on a committee.

(a) Basecamp seems to reduce risk by solving as many questions as possible before committing a project to it.

(b) Integrate early. This makes sense. You don’t want to build a car engine and a chasis and then work out, 3 years into the project, that the two don’t fit. Integration must come early and as fast as possible to avoid the problems and costs of them failing.

Creating Products

Adopted from a talk I stumbled across.

(i) Solve your customers’ problems:

• Listen to your customers.

• Note that what a customer wants and what they think they want might be two completely different things. Listen to your customers’ problems, but don’t listen to them when it comes to HOW to solve them.

(ii) Have a look at what your competition is doing. If they have good ideas: adopt them.

(iii) Ask: who will pay for it: and how much? But then again, you will not want to leap into something simply because everyone else is doing it.

(iv) Cost of delay

• General Grant understood this above all. There is a price and a cost for delaying. If you can do it now, and quickly, then do so.

(vi) Say no: if required

Air BnB

Some ideas from an interview Brian Chesky did

• Just get 100 people who really love your product - not like your product, but who LOVE your product. You can really only do this if you solve their particular problems. e.g. with AirBnb in the early days, the houses would be really nice, but people didn’t know how to take good photos.
• Don’t chase start up capital. Create a product that is profitable.
• What is your product? Is it the website? Or is it the house, and the host (to use the Air BnB example?
• Make the consumer really really LOVE your product.
• e.g. Stage 1: (i) Solve your own problem, (ii) do something that does not scale, (iii) find 100 people that LOVE it, (iv) get developers etc. who are competent etc.