Most startups that are trying to grow all have the following problems. Each team has no idea what the other is doing, and everyone struggles to prioritize and organize their goals with the mission of the company. These issues lead to a lack of focus and every team not understand which goal is theirs. While there is the old refrain that a startup is supposed to be crazy, this has the negative consequence of diffusing the energies of employees.
Startups need to redefine their work as a Factory Assembly Line from the C-level to Support. In this essay, I will attempt to give an opinionated attempt at how to go about focusing the energies of everyone to aim for the same target, reduce multitasking and allow for quick iteration.
One of the things that is useful is figuring out what everyone at the company is working on. Use a Kanban board which goes from high-level ideas to implementation from team to team. This allows for the following:
The goal is to move as quickly as possible from the left side of the board to the right working on bug fixes to features.
Every story is split into the smallest batch of work. It should go through the entire range of responsibilities from High-Level Vision to Production and Validation. It needs to go through Customer Development, Marketing, Sales, Engineering, and Support.
The Kanban Board includes the following lists:
The list should have a hypothesis for a problem either internal or external. A clearly defined hypothesis is critical. For example, "Installing Kubernetes will allow us to save money by using fewer servers and help us to deploy more software in shorter periods of time." Another example is, "Releasing a Linux tuning feature for MySQL will allow companies to worry less about the performance of their MySQL cluster and can alleviate certain problems with administrating MySQL."
The stories in the Plan list need to have a complete picture of what features needs to be implemented. It is a story of how to a feature would behave at the end of the day. Having no context around the story is useless as it doesn't have critical thinking around it. The Plan should have a couple of things first a complete description of the feature and the potential plan for how to tackle the problem.
For the complete description part, I recommend doing Blog First Development. Describe a feature as if it were to go in a blog post, and as the feature is built out the, it can be edited until it is actually released in production.
The second portion is a high level overview of how to tackle the feature. Create a couple checklists of potential hypothesises for the different teams and what might need to be done. Each team can then fill it out as needed but at least there is a high level idea of what should be completed.
The plan is for every single thing at the company, from including integration tests to a new sales and marketing plan. The goal is to get everyone involved and giving input on how they can help instead of teams getting siloed.
The energies of the company need to be focused. There should be a top 3 projects and nothing else on this board that should be tackled next and nothing else on this board. The movement from the Plan to the Prioritization needs to happen at the high level with input from the other teams. This should also be a variety of internal and external features.
By limiting the number of projects, you set an expectation funnel of the ideas that need to move on to the next stage as a company. This should be decided on a high level by the decision makers, and this is where management needs to step in. Focusing on a combination of things engages the entire company and no one team is seen as being favored.
Once a story is moved from the Prioritization List to Customer Development this is when things need to move quick and you can't backtrack. Customer Development is where you find out if the feature you want can be broken down further. What are the issues that you are dealing with and what is the prefered solution to the problem.
Customer Development needs to happen both for internal projects as well as external. For internal projects, this creates a good way for people who are knowledgeable about particular problems to give their input even if they are not officially part of a team. According to W. Edwards Deming the father of
Further, this is also where you should validate features that you want to implement for customers. This way you know if the feature is something that should be worth building instead of wasting time on things that no one wants.
This process should create several design A/B tests if there are forward facing. This allows us to test which features are going to do well as opposed to picking the best feature. Maybe this can also be a design in terms of just validating that this issue exists by seeing if people click a particular link.
Every feature should go to the marketing section whether internal or external. Internal projects get lost especially if they are technical but by having marketing look at it they can see if a feature or bug fix affects them in anyway that they might need to change in their emails, or otherwise. Again limit this to 3 projects. It is hard to calculate all the benefits of a marketing plan in one swoop so it makes sense to break it down into individual chunks.
Outbound sales people should also be looking at features so that they can change their email flows or what they discuss with customers as being on the pipeline. They should check off on the feature. Again sales should check off on a feature. Sales should also limit themselves to reaching out a couple personas at a time.
This is where a feature or bug gets broken down into individual chunks. This should be broken into the smallest features possible and all areas need to be addressed.
Implementation should happen quickly and in parallel if possible. Releases should happen in the dark behind feature flags if possible so code is being released to the customer even if it is gated.
QA and Support need to be involved in this stage before being released to production. Test the feature thoroughly, make sure the documentation is being written for the feature or updates for the bug fix. Make sure that all of this is updated and correct.
Code should be moved to production and all the pipeline should be ready for anything that affects any big issues.
Do a gradual release or a full release with the feature flag signed off by Marketing, Sales, QA, Support and Engineering. The code should already be in production and people should be able to use it. This should also be coordinated with marketing and sales as to what the end user sees. This creates a consistent message.
Make sure you can do validation. Was the feature successful and did it fulfil the expectation that you had about it? Is it something that was worth it?
The goal of all this is to take into account multiple disciplines and put them together into a giant organizational wide system. These methodologies include Getting Things Done, John Boyd's OODA Loop, Toyota's Lean Manufacturing, Agile, and Systems Thinking.
In this Kanban board, the entire organization goes through the release of new features and fixes bugs together. In the Toyota's Manufacturing anyone can at any time stop the assembly as the quality of the product and reducing waste is more important than continuing the line.
Take the time to think it out. Also tickets should only move one direction and if anything takes too long then it a beak in the assembly. Further as you can see the tasks go from a high level to specifics . Definition needs to happen at the top and everyone should push ideas. However the assembly needs to constantly be moving.