Let limitations guide you to creative solutions
There’s never enough to go around. Not enough time. Not enough money. Not enough people.
That’s a good thing.
Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.
When we were building Basecamp, we had plenty of limitations. We had:
- A design firm to run
- Existing client work
- A 7-hour time difference (David was doing the programming in Denmark, the rest of us were in the States)
- A small team
- No outside funding
We felt the “not enough” blues. So we kept our plate small. That way we could only put so much on it. We took big tasks and broke them up into small bits that we tackled one at a time. We moved step by step and prioritized as we went along.
That forced us to come up with creative solutions. We lowered our cost of change by always building less software. We gave people just enough features to solve their own problems their own way — and then we got out of the way. The time difference and distance between us made us more efficient in our communication. Instead of meeting in person, we communicated almost exclusively via im and email which forced us to get to the point quickly.
Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have.
Put constraints in place to help teams create value. Some examples are:
- We only want to put 3 days into this, then test it with customers
- Customers are complaining about this, where could we do less and still solve their issues
- How could we solve this if we only add one page to our application
How we naturally structure delivery of software: Plan, Deliver, Run.
Breaking down delivery into managable chunks: Cycles
Deliver something quickly, test it with customers (run), plan what’s next:
Iteration is the best way to stay open to what customers really need.
Software development has been steered by the word “requirement”, defined in dictionary as “something mandatory or obligatory”. The word carries a connotation of absolution and permanence, inhibitors to embracing change. And the word “requirement” is just plain wrong. Out of one thousand pages of “requirements”, if you deploy a system with the right 20% or 10% or even 5% you will likely realise all of the business benefit envisioned for the whole system. So what were the other 80%? Not “requirements”; they weren’t mandatory or obligatory.
The essence of embracing change is making small increments and checking if they are effective, frequently.
Subscribe via RSS