Lean (speed over perfection)

Many products (or tasks, designs, projects, etc.) are executed to perfection, yet still fail to get the desired results. Why? Often enough because they simply weren’t the right products to make. The initial vision might be great, but it doesn’t match the gritty reality of what real-world users want.

To build a successful product, we must first focus on building the right thing—perfection comes later. With anything you do, there can be risks, uncertainties, doubts, and assumptions—each very capable of throwing a wrench in your plans. That’s where the lean methodology comes in; validating your core vision, assumptions, and risks with the least amount of effort before moving forward. We want to increase our speed of learning, so we can quickly adjust the direction we’re taking, rather than going full-throttle in the wrong direction.

But how do we do this? At Publitas we combine the lean startup methodology with a few elements from lean manufacturing (as developed by Toyota). Below are the most commonly referred-to aspects:


Build, Measure, Learn

The most important tool in understanding and gaining the benefits of lean is the Build, Measure, Learn cycle:


Instead of taking on an entire project in one go (which could end up taking months to complete only to find out we missed the point), we minimize our risk of failing by splitting up tasks into smaller subtasks and experiments that can be easily executed. The idea is to take these smaller tasks through the build, measure and learn cycle so we can quickly understand if our core vision and assumptions hold up.

An often quoted example is that of IMVU. They developed a 3D avatar which integrated with twelve instant messenger clients. After launch, they discovered nobody wanted to use their 3D avatar on pre-existing messenger clients, but rather, on a separate network. Instead of building twelve integrations, they could have validated this idea with only one integration. Or maybe even none; what if they’d simply asked a group of test users how they’d like the idea of integrating with their existing messenger?

Long story short, they wasted a lot of time by going full-throttle on their initial product vision, rather than doing faster loops through the build, measure and learn cycle.


Minimum Viable Product (MVP)

The minimum viable product is the most pared down version of a product that can still be released. It’s made with a minimal amount of effort, used to test a specific value assumption. It’s essentially the smallest iteration of your idea that you can take through the build, measure, learn cycle.


Concierge MVP

Sometimes building a typical MVP might already be a step too far. Ask yourself the question: How much can I test, learn and validate without building a product or automation at all?

The Concierge MVP refers to the idea of manually providing a service that your product would ultimately automate. For example, Zappos launched their online store without even having a real product to sell.


Elimination of Waste

We aim to focus on doing the tasks that provide the most value at any given time. We use the urgent-important matrix to discover what is most important to us, but we can further sharpen our focus by removing ‘waste’ from activities and processes.

Traditionally waste comes in 7 different forms (as described in Toyota manufacturing principles): Transport, Inventory, Motion, Waiting, Over Processing, Over Production and Defects. While these apply to physical manufacturing, we can learn a lot by reviewing these in perspective of software development:

Transport—Moving information or product around. The act of ‘transporting’ does not add any value to the end product, so it should be avoided as much as possible. Examples:

  1. Back-and-forth communication without a clear purpose.
  2. Unnecessary communication lines.
  3. Non-centralised assets that are emailed or slacked around instead of using Google Drive.


Inventory—Anything that’s stored, but not providing value and not actively worked on. Also termed ‘shelf-waste’. Examples:

  1. Work-in-progress that is on-hold.
  2. Unshipped features and changes.
  3. Processes or operational expenses that do not deliver value.
  4. Non-smart, non-executed tasks in Asana (that have been collecting dust for over a month).


Motion—Unnecessary activity that reduces efficiency and potentially causes stress, harm, and frustration. Often caused by lack of organisation. Examples:

  1. Continuously searching for lost documents, tasks or information.
  2. Complicated deploy or update processes.
  3. Repetitive manual activities that could be Alimated (™).
  4. Overcomplicated Asana processes/moving around tasks too much.


Waiting—Literally waiting ;) Idle time, especially when blocked. Examples:

  1. Lack of resources to move tasks forward.
  2. Critical people are not available to move tasks forward.
  3. Required input or feedback takes a long time.
  4. Unreliably processes or systems.


Over-processing—Delivering a higher quality than is necessary. This is an important form of waste to analyze because it can be hard to detect with excellence/quality being one of our core values. Examples:

  1. Worrying about perfecting a solution or design before actually validating core assumptions.
  2. Trying to solve problems or edge cases that might not ever occur.
  3. Setting high requirements and tolerances too early in the development stage.


Over-production—Building more than is necessary. Examples:

  1. Building features too soon.
  2. Building features without customer demand.
  3. Executing tasks with an ‘activity’ mindset instead of a ‘result-driven’ mindset.


Defects—Anything that’s broken and needs to be fixed. Defects might seem very obvious, but especially when things are obvious, assumptions are easily made. So, when defects happen make sure you still consider applying the 5-whys! Examples:

  1. Bugs in software development.
  2. Badly written requirements (un-SMART tasks) resulting in faulty execution.
  3. Lack of maintenance on existing processes causing bad customer experience.


Just in Time (JIT)

As the name Just in Time suggests, the aim is to deliver exactly what is needed, exactly when it is needed. By doing so, all common forms of waste are automatically reduced. Why?

Instead of using large and unnecessary buffers, or an overly safe and redundancy driven mindset (causing shelf-waste, idle-time, over-processing, etc.), your focus is to deliver just enough and just on time. With a deadline on the horizon, you’re much more likely to find that lean iteration which could help you move forward.

If you think this creates a higher risk working environment—where a small error can cause a delay—you’re right. But that’s not all bad. By doing so, problems which would normally remain ‘hidden’, come to the surface and can thus be quickly solved at their root cause. This prevents problems from slowly growing into a scary abyss underneath the surface.

Ultimately, just in time production helps you focus on what is most important while keeping waste to a minimum.