Being lean, means that you only do the minimum necessary work to ship your product and learn with it after it’s released.

Being lean is not being sloppy

An important thing to realize is that lean is not sloppy. If you do only the minimum necessary to ship a product, you’re going to have more time to iterate on that minimal set of features. The consequence is that you might release fewer features, but the ones you ship:

1. Address the pains of your customers by their root;
2. You had time to iterate and test them over and over, so you have more confidence in their quality.

Iterate, iterate, iterate

Everyone is biased. If you truly understand this, then its corollary is obvious - Everything I build is based on my own perception of the word. My own pains are not the pains of my customers.

This is an amazing thing to realize, because now it becomes clear what you need to do:

1. Understand what the real problem is;
2. Your first solution will be wrong, so you’ll need to iterate until you get it right;
3. Get metrics;

If you are lean, you’ll be able to define the scope of problem, build a solution and get metrics. Then you’ll learn one of two things: that your problem definition is wrong, or that you’ve defined the problem correctly, but the solution you came up with does not really tackle the problem.

If you didn’t understand the problem, you’ll need to redefine it. Sometimes, it’s more productive to pivot (change a single variable) instead of redefining the problem from scratch.

If you got the problem right, but the solution you came up does not really tackle the problem, then you need to iterate and get metrics to learn what works and what doesn’t.

On leaving a documentation trail

If you know that your original solution to the problem will be wrong, or even worse, you should be tackling a completely different problem, then you know that leaving a documentation trail of the decisions you took is not that relevant.

Creating a documentation trail of your decisions seems important at first sight. After all, if someone joins the team later on, or if someone in the future (including you) needs to introduce changes to the thing you are building, how will they be able to understand the rationale behind all the decisions you took?

But if you truly are going to iterate, any documentation trail you might create will either be totally irrelevant or outdated.

An example

At OutSystems we’ve created a learning path that allows developers to learn the basics of the OutSystems Platform by watching some videos.

We initially took around 3 months to ship 40 videos. These videos start by explaining how to register to have your own personal development environment on the cloud, and guide you to create 3 different web applications while teaching you about how to model your data, implement your own logic, and create and polish the UI.

A while after the videos were released, we started to learn what worked and what not. What needed to change, what was working, and what was missing. With this knowledge we could now iterate on what was already shipped.

So my question here is, imagine that after shipping the videos and learning that a video is not being effective, does it matter that we have a documentation trail that we can use to understand why we created that video in the first place?

If you don’t have an high turnover rate, and OutSystems doesn’t so our team hadn’t changed, every one remembered why the video was there. Yes, everyone might remember different things since we didn’t left a paper trail, but does it really matter?

What matters is that today we have more information than when we originally released the videos. When we released them, we had our own bias about what we think we should do and how we should teach people.

Today we not only know which videos are not working, we know why they are not working. Today we have different bias, but we have much more information than we had when we launched the videos.

Irrelevant information

So, even if we had a paper trail, and we could precisely find out why that video is there, would it matter?

Even if the video was there because the CEO personally asked you to, do you think he would mind if you changed the video? If we was really interested in why you changed the video, when you told him what you had learned and were able to complement the explanation with the metrics you’ve been collecting, I bet he would understand.

If you could use that opportunity to explain how many customers he is losing because of his favorite video, I’m sure he would get out of his way to help you solve this problem that is having real impact on the business.

Last thoughts

As always, if you create critical systems such as airplanes, nuclear power plant software and such, just ignore everything I’ve said. In those scenarios, leaving a paper trail might be crucial to understand why something went wrong, and how to fix it in the future.

But for the 99% of us that does not work with critical systems, you should strive to be lean, and challenge if you really need leaving paper trails.