It is believed that product managers should help a company do something that makes sense and advise against doing something that doesn’t.
It is also believed product managers focus the team on action items that bring value to the business, items that users like, items that increase sales (such as average check, LTV, ROI and many other buzzwords), and cut off everything else that is unnecessary.
This is similar to the Lean approach, and most of the product managers I know share that approach.
At the same time, the product workflow includes activities that aren’t very useful. For example, excessive meetings and synchronization of ideas regarding the product. I am sure that if the products spent the same time communicating with users, they would be more beneficial for the businesses that utilize them.
It seems like the people who are responsible for the success of the company aren’t very effective at ensuring this at all!
A Brief History of of the Theory of Product Management (Not Really)
Almost all product companies understand what a product manager should do: test product hypotheses, prioritize development, launch MVP on the market as early as possible, collect feedback, consider unit economics, test new marketing channels and so on.
It’s much easier with the development team because it should do what it’s told by product manager and his assistants: analysts, testers, and marketing managers. How to do it is also clear: there are many approaches and methodologies at your disposal, such as Scrum, Kanban, and Agile to choose from in order to accomplish your goal.
Now let’s look at the product again, specifically, what it should be able to do... How can we organize the process in order to maximize effectiveness? There are no established paradigms on the market yet, so each company comes up with something different to solve that problem.
In this article, I will share with you some cases that show how the processes of product companies at different stages of development are arranged.
The cases you are about to see here are all my personal projects for clients; they belong to my clients whom I have consulted. The material will be as depersonalized as possible, but no less useful.
0. Startup looking for its product/market fit
Or when the product is not yet ready.
Imagine a team of 3–4 people who decided to form a startup. At the moment, they only have an idea that remains to be verified. Most likely, at the start, the team looks like this:
Author of the idea. Most likely it is a product manager.Developer. Because everyone knows that developers are needed for any kind of technological startup.Designer. No startup is possible without a designer.Analyst (optional).
At this stage, it’s pointless to introduce something more complicated than a cork board, because if such a small team cannot agree on how to work, they are unlikely to succeed in doing business with clients.
Their main task now is to test as many hypotheses as possible as quickly as possible.
In general, the process looks like this:
Of course, each hypothesis has a preparation stage, at which it is determined what to test, what the audience should be, how to test on that audience, and how to interpret the results.
After direct testing, the Product Manager needs to collect data, analyze it, and then determine whether the hypothesis is good or not. Perhaps even formulate new hypotheses, if needed.
The process of passing the hypothesis from the “Idea” stage to the “Done” stage is called Lead Time. And it is the most important metric to optimize, if you are a startup that is looking for a product/ market fit.
Some startups introduce Scrum at this stage, but soon abandon this idea, because meetings and stand-ups take too much time. But how do you optimize this process?
Odd as it may sound, in order to work on more hypotheses during a period of time, you need to limit number of hypotheses you work on simultaneously. In Kanban we call it WIP-limit, Work In Progress = a number of tasks in progress at the same time.
When you work on too many tasks simultaneously, you spend most effort on switching between them, instead of working on them. Thus, in order to save some time, teams limit the number of tasks in progress. Here is how it looks like.
An example of a real board using Kaiten.
(Full disclosure: I work for Kaiten.)
Such an organization of processes can work for a long time, as it allows you to quickly drive cards through the system. However, all good things come to an end, and this is what goes next…
1. Startup with a good product/market fit
When the value hypothesis is found, and you need to build the product.
The startup has found its niche and the values that users will pay for. Now the product needs to be developed. At this point, a development team is hired, and it turs our that they cannot work in the old system. If the product manager can test ten hypotheses per week, then the developer can complete only one task per week (numbers are random). In this situation, control and manageability of the product development process is lost.
Moreover, developers have their own workflow, because development stages tend to differ from the stages of hypothesis testing.
The question arises: how do we ensure that developers have a positive relationship with product managers?
This is a general list of tasks, also called the “backlog”. Product managers throw a bunch of tasks to this list, and developers take turns completing them.
The problem is that Scrum does not explain which of these tasks to do first. Product manager is smarter, let him/ her prioritize.
2. The product already has users, and their number is growing
When there is a core group of regular users, and Retention has started to plateau.
Problems begin after the product is launched, as tasks from two other sources start to get into the backlog, such as bug reports from users and suggestions for refactoring code from developers.
Bugs always appear when a product has users, and developers really need to work on the architecture, because if this is not done, after a couple of months the product will fall apart.
All this leads to 200 tasks in the backlog, and it is completely unclear which ones to do first.
The first thing you can try to do is break the backlog into three parts. This visually simplifies the challenge, but if the team has 200 tasks in total, and they physically manage to complete only 10 in a week, then with 100% probability we can say that they will never do them. Why? Because something changes every week, and there will always be new tasks, insights and hypotheses into the product. After six weeks, the product can pivot and go another way.
Let’s resort to Kanban again: it says that you need to enter limits on the maximum number of tasks in the list. If a team, for example, enters a limit of ten tasks per list, each week it will need to prioritize only 30 tasks, and not 200, as it was before.
But how do we minimize prioritization, or even abandon it? The latter seems insane, but only at first glance. Watching self-organizing teams, I saw enough to say that refusing to prioritize is compatible with effective work.
The first step towards this is to let developers decide for themselves what to do first. When I talk about this at conferences, they usually object to me, saying “But how so? If the developers are given free rein, they will only deal with architecture: they will take tasks from the list in turn, until all ten are redone”.
Yes, this is possible. But not because the developers are “assholes,” and they don’t want to benefit the product. On the contrary, developers, as a rule, want to offer a bunch of ideas for product development, and are ready to implement them (if your situation is wrong, then your problems are much more serious than the organization of processes).
Developers may want to rewrite architecture in two cases:
Most likely, the critical moment has come when there is no way to move the product forward without rewriting the architecture; the product will simply fall apart. This occurred once with the startup Dodopizza. Dodopizza grew from 200 to 400 pizzerias in a year, and due to poor architecture, the system began to lag at the 250th pizzeria (and this system is used at all outlets). As the plans were to continue to grow multiple times, the losses from system failures grew exponentially.Developers do not understand why this task is needed, or how useful it is. Unfortunately, not all product managers are ready to follow the example of Dmitry Potapenko, one of the owners of the Pyaterochka network (one of the biggest supermarket chains in Russia): every week Dmitry is working at the cash desk one day and washing the floors in order to personally see the faces of customers, their moods, interests and problems.
The second problem, of course, is much more common. Products move away from their customers, while developers answer complex questions of the second technical support line every day and fix bugs. This can lead to the fact that the products simply set goals, without explaining why. This is the equivalent of not “selling” your tasks to developers.
To solve this problem, just enter a simple rule:
“No one starts work until he/she understands why this is necessary”
This ensures that you start treating your developers on an equal footing, as adults, and as independent and responsible people.
To fix this rule at the system level, you need to enter another board for products with the stages “Design”, “Sale”, and “Solution”. Due to the fact that the products will greatly save on senseless prioritization, they will free up time for a little work on selling their tasks to developers. If developers understand that this task will bring two times the growth, or that all users have long wanted this feature and will use it, they will do it first, despite the fact that the work can be difficult and unpleasant. When a person understands why, it is easier for him to cope with difficulties.
Of course, at first it will be difficult to work under the new rules. To ease the burden of developer responsibility, Kanban suggests introducing (yes, another limitation) a fixed ratio of tasks in the work from each list.
An example of a development space in Kaiten.
This relationship can and should be negotiated and always discussed, because at each stage of product growth the ratio will be different. For example, at the start of a product, 0–5% of the time should be spent on architecture, and 30% of the time should be spent on bug fixes. When a product is already mature, this ratio may change, because a mature product has high quality requirements.
3. Business with streamlined processes and a product line
When there are several product teams and several development teams.
As a matter of fact, product managers do not care about the specific steps in the development team. They are only interested in the general view, which means “Queue”, “In progress” and “Done”. The lead time department always has their attention, also. But how do we automatically collapse a development board to three stages so that you do not have to lead two boards at the same time?
I don’t know the solution to this problem in the offline world, when sticker cards travel on a corkboard — in this case, you really would have to keep two boards, and constantly synchronize between them. In the online world, there is Kaiten — our product that is specifically designed to work on Kanban and other flexible methodologies.
In Kaiten, you can create spaces with boards for different departments, while displaying the same boards in different places. For example, in the development space, the entire kitchen of the products is not needed — they just need to see the last board “Design”, “Sale”, “Add to Cart”, and their development board with the detailed steps that they can change as they want. Products can insert a developers board into their space in a simplified form, and if necessary open the full version of the board.
The spaces in Kaiten allow the company to work at different levels, and at the same time be synchronized.
If a new development team arrives tomorrow, it will easily integrate into the existing process.
When a company becomes very large, with a board of directors and an entire orchestra of products, this model can be scaled even higher, to the level of top management. Again, in order not to overload the space of directors, Kaiten allows you to place simplified product boards.
Summary. Benefits of Using Kaiten
Thanks to an end-to-end tasking system, products can save time on prioritization and synchronization. This allows you to devote more time to the main work of testing new hypotheses, communicating with users, and so on.
Using Lead time tracking, you can get valuable information about the effectiveness of different departments and the company as a whole. Statistics allows you to see the distribution of completed tasks by day from the beginning of their start. This is useful when drawing up a roadmap or when promising customers deadlines.
Looking at the graph, we can say: the received task with a probability of 50% will be completed in four days and with a probability of 85% in 12 days. You longer need to guess the timing of the response to customers, and forecasts will no longer be based on subjective assessments of developers.
The analytical module in Kaiten allows you to build such graphs in two clicks.
Roadmaps can be styled like JetBrains. They sort all future features into categories:
We’ll do it for sure.
We’ll probably be on time.
If there is extra time left.
This gives an understanding of what to expect from the new version, and eliminates the usual, but useless Gantt diagrams.
Placing limits of simultaneously performed tasks and limits on the maximum number of tasks in the list allow you to focus, complete tasks faster and reduce the costs of prioritization.
Kanban is a set of tools that each company adapts to its needs, and not vice versa. That is why it is suitable for companies of all sizes: you just need to introduce new rules as you grow.
Kaiten is designed to work in Kanban. If you want to try Kaiten, go to https://kaiten.io and write to our support contact, “I want to work. I’m tired of prioritizing”, and we will give you an additional month of access for free when paying for a year of the service.
Share this article with your friends, so that they stop wasting time on unproductive classes and meetings and maximize their productivity and effectiveness.
Last, but not least, if you have questions how to improve processes in your company, feel free to email me at andre@kaiten.io
Thank you!
Stay kind!