The following are a mixture of my thoughts/comments + a summary of what is contained in Basecamp’s “Getting Real” book.

What’s your problem?

Solve someone’s problem, and solve it well - preferably without bloat, unecessary features, or expense; they advise that if you are experiencing the problem yourself, then you will know where it falls short, and where it needs to improve.

They advocate that passion is key. I would agree: you need to be interested in solving the problem, the best/simplest/easiest way possible, and that you need to constantly improve things. Perhaps this is best illustrated with a situation where this is not the case:

Venture capital guys: they just want money. Fast money. Easy money. Solving a problem is a secondary concern. Satisfying customers is a secondary concern. Fundraising and exiting is their God. They lack passion. If you don’t have an exit strategy, what can you concern yourself with but your customers?

The above point segues nicely into the next topic Basecamp elaborates on:

Funding

Limit the scope

Basecamp are saying: solve the problem, as cheaply and as minimally as possible. Cut it down to the bare bones. You are thinking of hiring a front end React team? What if you didn’t have that luxury? Do it in HTML, with a single developer. You want to hire your own dev-ops team? Just use Heroku. You want to add an extra feature? How would you do it without that feature, or with a slimmed down version of that feature? Be ruthless in cutting the scope to solve your problems.

This allows you to solve problems quickly.

Fail early and fail fast

If something’s gonna fail you want to know as early as possible, and as cheaply as possible. The above point will ensure this.

Focus on the customer

Ever heard of Bezos go on about this? If you don’t give the customer what they want, guess what: you don’t have a customer. If you don’t solve their problems: then you don’t have a customer. The customer is your God. Basecamp is of the opinion that if you’re backed by venture capital: they become your bosses and all they want is to make a quick buck. In other words, the quality if your product will tend to suffer.

Fix Time and Budget, Flex Scope

Scale back on the scope if required

You’ve got some time and a budget. And you want to do something. Unfortunately, you are not the a federal Government with unlimited amounts of time, and a never ending budget to chase down never ending rainbows.

In private enterprise: these bounds remained strictly fixed: if you traverse these boundaries, then you’ll have to dig into your own pocket, or spend years which you do not have! The key point which Basecamp seem to be making here is this: if you can’t do what you want, with the resources you have, SCALE BACK on the scope - scale back on what you are trying to do and the grandeur in which you are trying to do it in. Chances are, that you can still solve a lot of your customer’s problems with a scaled back scope of what you are trying to do.

The benefits of scaling back are: (i) you’ll have to get creative on how to solve your problems within your constraints, and (ii) you will be forced to focus on what is REALLY important.

Minimal Version First

A better approach, improving upon Basecamp’s methodology, would be to develop a minimal version of the feature/app. Barebones. Nothing else. And to then iterate on that over time. First get it fully integrated in some basic form, and then iterate. Absolute simplicity, in one week. Then make it rich over the rest of the cycle.

Have an Enemy

• Know what your app shouldn’t be - and that’s where you can go.

• Understand what they key problem is, and try to solve that problem.

It shouldn’t be a chore

Basecamp seems to advocate having passion. I think what they are really trying to say is: make your product awesome. If it’s done half-ass, then it will show.

Less mass

You wanna be able to change, and quickly. This is more possible with smaller and “agile” teams, than with large bureaucratic structures, where it is difficult to move out of them. Here is a list compiled by Basecamp which exemplifies leanness.

Lower your cost of change

Basically, the Basecamp guys are saying: do not make it difficult to change. You don’t want endless meetings by folks who don’t know or care about certain things, making calls on things that don’t even matter. Allow yourself the permission to make the necessary changes quickly and efficiently:

• small teams.
• less meetings etc.

Use small teams

Basecamp says build your product with no more than three people: front end, back end, and someone who can go between. I agree: keep teams absolutely small. Tiny. Adding more people does not mean that the project will complete faster. This eliminates the possibility of mis-communications and mistaken assumptions from perpetuating.

But I will say something more: I say start with one person. The lead. He or she must be the brains behind the entire operation. If required, the lead will coordinate with other trades as required.

Customer service

Look after your customer. Be responsive to their needs. Call centre operators do not care to make changes.

All of these issues can be obviated when you have a small team.

Embrace Constraints

What’s the point of building a house if you can’t finish it? If you run out of money half-way, it will be a living shrine to your ineptitude. No good comes from it. If you don’t have cloth enough for a coat, then you might have to settle for jocks instead.

We ain’t the government, with unlimited budgets to boondoggle tax payers till the end of time. The hard reality of limitations has got to force you to think creatively.

• Fight the war without bullets.

Case Study: How I limited the Scope for a “required feature”

Case in point: I’d been clicking around to see how other sites are handing this problem. They have an address book. They have teams of react programmers on hand. I don’t have that luxury. I need to solve this problem in 2 hours. How did I do it? I limited the scope. I didn’t even attempt to build a react app. I was using Stimulus JS so I reached for that, and simply changed the URL we were fetching from: the entire list of universe of users on the app.

Is it a good idea? No. But we hardly have any users, so it isn’t much of a problem at the moment. Freddie might have to choose from 50 users, via an ajax selection menu. Sure it might be annoying for him, but it’s not that bad, I think. Ideally, I would have liked to scope things to people in a particular project. Then it struck me. I don’t need a react component. All I need is a boolean switch. If the switch is on: search within the project. If it is off - then search across the entire universe.

That idea - of limited scope, saved me countless hours: it solves the problem, and cuts the cloth. More innovative solutions like this are needed in order to ship products to customers. It’s the only way.

The Basecamp guys effectively say this in this chapter of their book.

What’s the big Idea?

Ignore Details Early on

What I understand basecamp to be saying right now is: don’t spend too much time trying to optimise something. There’s a hint of the pareto principle in what they are saying (the Pareto principle says you get 80% of the reward with only 20% of the work.) So long as you solve the majority of the problem, then you’re good. You don’t want to be spending days and weeks on minor details that actually don’t matter (right now).

Makes sense, right?

The most important thing you can do when building something is to get some paid users on board as fast as possible: and necessarily to do so, you must solve some big problems - the majority of their problems. You wanna worry about solving the big 80% problem, rather than stressing about the 1% benefit that your users might have.

Look at my blog. I get my ideas down on paper. They serve as a reference - first and foremost - for myself. If they benefit others: great! But, I by no means sweat the small stuff, on the blog. Should providence deem it important that I revist a post and then repolish it: then I will do so.

It’s a problem when it’s a problem

I’ve had big arguments regarding this