Running a HALO product development team

A set of simple product development practices for creating a hive-mind view of plans, defects, customer feedback, and the production pipeline in a “Highly Alinged LOsely coupled” A+ team

New product development is very hard because it’s about making a string of good decisions in a complex environment with a large degree of uncertainty. In this, there’s no substitute for A+ people. If it’s possible to obtain the same results using processes or philosophies with lesser skilled people, I don’t know how to. But even A+ people fail if they’re not well coordinated.

This post describes a very simple system for running a HALO team. The primary influence is Netflix “Highly Aligned Loosely Coupled” philosophy for managing complexity: hire the most skilled people, align them, and get out of the way. This means embracing and demanding skill, transparency, creativity, freedom, responsibility and discipline.

On top of this, this HALO system maps a few core principles borrowed from the genius philosophers at Toyota that invented Lean. At its core Lean is about values and respect for people first, designing the organization to help the people second, and last about tools in service of the other two. Every organization is different in purpose, size and capabilities, and not all Lean principles apply well everywhere. I’ve borrowed a few that makes sense in the context of HALO.

HALO is primarily a framework communicating the state to everyone involved to make the best decisions possible by having access to a current, digestible, and complete data set.

There are no processes, and very few principles. It is simpler than “agile” and it can be summarized in a single diagram, see below. The diagram shows 4 HALO tools used to create an organizational hive-mind view of our current state. All tools are implemented as lists in Asana. This plus a real-time communication tool like are the only two software products needed to run a HALO team.


The feature stack contains all future work, the production pipeline is vertical kanban board used for tracking all current work, the feedback buffer filters the feedback in the loop, and the bug list contains 4 different severity buckets for defects found in production.

1. Communicating Priorities 

HALO team tool: Feature list

We simply put all features in a stack and rank them top to bottom. This makes it impossible to say that two things are of equal importance, which is great since this is sometimes tempting and often miscommunicated by mistake. The screenshot below shows what it looks like in Asana.


The stack ranking also makes it super simple to maintain the feature list. Stuff that is important near term, and hence close to the top, generally remains well prioritized. Stuff that is a bit further down and hence “out of view” can remain unorganized for now.  There’s no time wasted wading through, organizing and prioritizing stuff that may or may not be important later.

(See this earlier blog post for more on prioritization.)

Principle: focusing on customer value

A core Lean principle is that everything that doesn’t create value is wasteful. This may not seem like a very hippie way of viewing the world, but it resonates a lot with most type A people. 

When we communicate priorities we make it clear how something will create value. Often we do this by writing a short story (see screenshot above) for a feature in the stack. This helps drive the design process and validate that a design achieve its purpose.

Principle: Mieruka visual controls

A friend of mine once jokingly said “Pictures are to stupid people what words are to smart people”. Jokes aside, I think we can all agree with Seal Team 6 that visual signals in many contexts are more efficient communication tools than words and sentences. Our Lean Japanese friends call this visual control principle “Mieruka”.

We try to use visual controls when we want to communicate important stuff with zero cognitive load. As an example, for most web products there are essentially 3 ways to create customer value: 

  • Acquisition, i.e. helping the customer find out about the product
  • Activation, i.e. helping the customer start seeing the value of the product
  • Engagement, i.e. helping the customer derive value on a regular basis

By tagging the feature with one of these different categories, we make it easier to process information without or before reading the text (see screenshot above.) As an example, you can easily see in which pieces of the puzzle you’re investing at the moment.

Principle: constraints boost creativity

The creative process is chaotic and shouldn’t be controlled. However, it’s usually a good idea to direct the creative laser beam. It’s hard to do great work when nibbling away at tons of unrelated stuff in parallel. 

We usually approach development by attacking one specific theme at the time, for example “make the product more fun to use”, “help users source job candidates”, etc. We call these things “episodes” (inspired by Asana). Whenever we start a new episode we move all of the features in the stack that we want to work on related to it to the top, then we gradually feed them, one by one, into the production pipeline.

When all the features have been fed through the pipeline, we pick a new theme.

2. Communicating the state of current production 

HALO team tool: Vertical Kanban

We track the state of features that we are implementing in Asana in a list with four buckets: Design, Implement, V&V, Accept:


Principle: Heijunka production leveling

Inspired by Toyota’s Heijunka production leveling principle, we try to keep each bucket filled to approximately the same level. This isn’t a process, it’s a simple guiding principle that helps us iterate fast, and keep things from piling up. The goal is to avoid things like a design being finalized and then spending a lot of time waiting to be implemented. While a design is just sitting there, the designer might learn a bunch of new stuff about the customers, and by the time it’s about to be accepted and released to the customer it might be obvious to everyone involved that the design is outdated = FAIL!

Principle: Kanban boards

Toyota created Kanban boards to help them implement production leveling. Kanban boards are awesome because they visually signal the state of the pipeline, and it’s super easy to see if things are piling up meaning because that means that columns will differ in height. The concept dates back to the 1950s, but most software people came in contact with it through scrum or Trello.

It’s much more important to understand the ideas behind production leveling and Kanban than to use a specific tool. Since Asana is very good at a lot of other things than Kanban boards, we use it to simulate them. It is not as good as a true 2-dimensional Kanban board but it’s good enough that the advantages of keeping all our information in a single place is a net win. The tools are there to serve you, and if you have to many of them you become a slave to them.


3. Communicating product defects

HALO team tool: Defects

We categorize failures of software we’ve already shipped in 4 categories.

  1. P0 defect - Drop whatever you’ve got in your hands, even if it’s a carton of eggs, and fix it immediately
  2. P1 defect - Calmly wrap up what you’re doing and then proceed to fix it
  3. P2 defect - Fix later, if you feel like it
  4. P3/P4 defect - Note/ignore

We track all defects in Asana and it looks something like this:


Principle: Jidoka quality control

We want to ensure consistent high quality. When something leaves the production pipeline it should be tested well enough to be free from severe bugs. We call these types of severe bugs “Priority Zero” and “Priority One” defects. In the fast and lose world we live in the word “bug” just doesn’t seem to emotionally communicate the right level of severity. 

When P0/P1 defects are found, by a customer or automated system, we shut down the new feature production pipeline. The reason for this is that something got seriously f-d up to a point where we don’t want to just brush it off and move on. We want to understand why this happened, identify the root cause, and address it so it doesn’t happen again.

4. Communicating customer feedback

HALO team tool: Feedback buffer

Human interactions are very powerful. Somehow the last thing you heard always seems to echo the loudest in your head. Acting immediately on customer feedback is like driving a car without shock absorbers - each external stimulus hits your body immediately. It’s not pleasant. Even a 918 Spyder has shock absorbers. 

Emotional chock absorbers can be implemented through the use of a a feedback list. Instead of acting on stimulus right away, you can put it in a queue, and process it at some later date when you’ve had a chance to sleep on it, gain more insight, etc.

The processing itself usually means one of three things: adding/revising a bug, adding/removing/revising a feature, or moving the feedback to “noted”.


Principle: Genchi Genbutsu “go and see” 

Genchi Genbutsu is another core Lean principle. It means “go and see”. 

The idea is that the only way to truly understand what’s going on with an application is to use it yourself, and to observe other people using it. The same thing of course applies to pretty much anything: if you want to understand what’s going on in a dev team, research project or dysfunctional family, you need to immerse yourself with the people. You can’t do that from 10k feet. You also can’t do it by asking people what’s wrong, and expect them to provide you with a thoughtful analysis. It’s not how the brain works. There’s a simple way to get to the bottom of issues though: when you’ve found a customer problem just ask the customer “why?”


A halo team can be run with tools simple enough to be summarized in a single napkin size diagram. With a team of A+ people embracing and demanding embracing and demanding transparency, creativity, freedom, responsibility and discipline it’s liberating and fun, and produces kick ass results. 


Footnote on continuous improvement

Some people think that the world’s most talented people don’t use processes. This is correct in the sense that they don’t need an outside person to tell them how to do their job, but incorrect in the sense that they do have very clear mental models for how to approach things: refined, ingrained and applied on the fly. These mental models are often very complex, and even if they could be extracted from a person’s head and written down on paper, they would only help people of less experience and skill. 

A core principle of Lean that wasn’t mentioned above is “kaizen”, i.e. continuous improvement. Like Toyota we believe in relentless pursuit of unattainable perfection, but we approach it differently than them. This is the area where we’ve looked at Netflix for inspiration rather than Toyota.

We’re are not obsessive about documenting processes and measuring results. Instead we hire people that use introspection to seek opportunities for improvement, and when they find them to distribute them by leading with example rather than writing memos. Great tactics are contagious.


Thanks Sean Abrahams and Per Jonsson for reading a draft of this.