Skip to content

Latest commit

 

History

History
104 lines (45 loc) · 7.72 KB

incrementalism.md

File metadata and controls

104 lines (45 loc) · 7.72 KB

Incrementalism in Practice

The largest lesson I learned from startups is to be incremental. Yeah I know, you’ve heard this before, but I want to add some nuance here and ground this in action.

If you first start reading about how to do startups (in a book perhaps), you'll find that people stress on being incremental and iterative. You'll hear popular bromides: better done than perfect, do things that don't scale, make a lean startup.

You know there are good reasons for this and people repeatedly tell you: you'll move faster and learn more. You'll fail fast!

While the advice is good, I think there are two problems with it: 1) we don't know what being incremental means on the ground level, and 2) the pros are so exceptionally good that it sounds like snake oil.

I’ll try to address some of those here.

The Hidden Treasures

Let me go through a couple of ways an incremental perspective can manifest in actions that help in an enormous way.

He Who Hesitates

In the past (and even now) I've had problems with doing big tasks. Small ones are not a problem, however, if it is something that will take multiple days of work, I have a problem getting started. I always think: I'll need a couple of days in a row cleared out to finish this. So I can't start now, I've got meetings all day afternoon. Right?

This is where incrementalism can be a big help.

Any time you hesitate to begin: I need a full day to get started, I'm traveling this week so I won't start exercising this Monday. We can't get started building this until the next API is out. Think incremental.

Incrementalism is hearing those excuses and tuning them out. Working for an hour at a time on a book is not the best way to get it done, the context switching will hurt, nevertheless, incremental work is the only way that it will get done—especially if you are working at a startup where every other day there is another explosion.

That type of incremental mindset is a way to take the abstract idea and put it into practice. In the short run, you'll start making faster progress on your big goals. And in the long run you'll get better at managing the context switching and get faster still.

Incrementalism is a vaccination against procrastination.

Better Design

Designing features in the abstract is difficult. In fact, doing most things in the abstract is hard. This is why we are starting to see more and more AR/VR use cases in film and design. Making great choreography is much easier if you can make tweaks and see what happens. Creating an excellent interior design is much easier if you can walk inside it and get the feel.

Getting the feel of things is essential for making good design and product decisions. Just playing with the app or holding it in your hand can inspire you.

Incrementalism is the way to get that feeling the fastest. When you are unsure of what the best design should be and are paralyzed in that analysis, think incrementally. How can I get the product to a state where I can play with it sooner. Then you'll start to be able to make better designs.

There is no better way to tell what something needs than by playing with it, feeling it in your hands, or putting it in the hands of your users. You may be surprised at how happy or sad people are with half-baked products.

Resolving Arguments

Oftentimes, you'll be stuck in a situation where team members want to build a specific feature in different ways. Instead of trying to out logic each other or pull rank, think incrementally.

You and your team will agree on some of the steps to reach a solution. Do those steps first. Then you'll find yourselves seeing the problem from a brand new perspective. Other times you'll find yourself more invested in the project after putting in work, and that helps when it comes to compromising.

If the above doesn’t work, go for the version that can be implemented fastest and get your hands on it. You'll either be convinced by the finished product or you'll find something else has a higher priority.

If you are still in disagreement, now is the time to gather data. The person that went out of their way to prove out their feature design should be the one that makes the decision. This last bit is not incremental, but something I have found to work.

Sum Of The Parts

Oftentimes, you'll find yourself facing down a monumental feature request and unsure of where to start. The feature is so big that it is hard to spec out the full design and even harder to estimate how long it will take.

If you are ever in that situation, think incrementally. Spend time to break the feature up into smaller chunks. Once you unbundle the feature into much much smaller ones (less than a week for one person at least), you'll find you get tons of benefits:

  1. Time estimation: the larger the project the worse your time estimates will be. People are good at estimating projects they have done many times before. And while it is not impossible to have experience pushing many big projects, you’ll find that most people have more experience estimating how long shorter projects will be.

  2. Collaboration: part of the boon here just comes from writing down things that were previously implicit (but there will be another article on that). The other benefit of small tasks is that you can more easily split them between more than one person. Don’t get me wrong, sometimes one person projects are okay, but I’d always advise against it initially.

  3. Prioritization: Prioritization is a much more natural way to decide on what features to build next. It's not vetoing features or tearing up other peoples' ideas, but instead, you are just acknowledging that we can't do everything at once. Too often we have wishes without constraints, and forgetting about those constraints can bite you in the butt. You'll end up missing deadlines, breaking promises or working yourself to death. Prioritization is a way to work while recognizing resource constraints.

Don't Build For Edge Cases

A lovely benefit of incrementalism/prioritization is that it will allow you to think about the core of the application. What I have found is that 50% of the application code is for dealing with edge cases (and near 80% of the complexity).

By being incremental you focus on the core use cases and make your product with those in mind. This focus in itself can be a massive boon to other areas of your business.

Build At Your Scale + 1

Good artists copy and the great artist steal. You'll find yourself doing the same thing at startups. Copying features from other startups in related categories can be a great way to leapfrog their progress. However it leads to a trap.

Copying things from startups that are too far ahead of you can have you over building very easily. Copying complex designs from a series D startup when you're still a series seed, creates a ton of extra work every time you iterate on that feature. And believe me you'll be iterating a lot.

The simple advice is only copy things from your competitors that are one or two stages ahead of you. This way you're Still leapfrogging, but you're not tying yourself to complexity that you can't afford to maintain.

Small Victories

A small but notable benefit to incrementalism is that you are always finishing something. You always have room to celebrate, and the celebration can be more easily spread out because it happens more often.

Always Ready

One final little benefit is that if you are incremental and prioritize well, you’ll be better in crises. You will have already agreed on what is important and focused on it first.


In Sum

Thinking incrementally is essential—especially if you know when and where to apply it. Hopefully the above can give you some very actionable advice on implementing incrementalism.