It is a common belief that Product Managers should help a company do something that makes sense and advise against doing something that doesn’t. They guide the product development process, helping the team focus on action items that bring value to the business. This includes items that users like, items that increase sales (such as average check, LTV, ROI and many other buzzwords), and items that cut off everything else that is unnecessary. This is similar to the Lean approach, and most Product Managers I know apply that approach.
At the same time, the product development process includes activities that aren’t very useful. Examples include excessive meetings and synchronization of ideas regarding the product. I am sure that if the Product Manager spent the same time communicating with users, it would be more beneficial.
Oddly, it seems like the people who are responsible for the success of the company aren’t very effective at ensuring this at all!
A Bit of History
Almost all food companies understand what a Product Manager should do: test product hypotheses, prioritize development, launch the minimum viable product (MVP) in the market as early as possible, collect feedback, consider unit economics, test new channels and so on.
It’s even easier with the product development process, in that it must do what the Product Manager and his assistants tell it: analyze, test, and market. It’s also clear how to do this. There are many approaches and methodologies at your disposal to structure the product development process, such as Scrum, Kanban, and Agile. You have your choice as to how you’ll accomplish your goal.
Now let’s look at the product again, specifically, its function. How can we organize the product development 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 cases that show how the product development processes of food companies at different stages 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 advised. The material will be as depersonalized as possible, but nonetheless useful.
0. Startup Looking for its Product/Market Fit
This is the stage when the product is not ready yet.
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. At the start, the command will most likely look like this:
- The Author of the Idea – they’re likely to be a Product Manager
- Programmer – everyone knows that programmers are needed for any kind of technological startup
- Designer – without a designer, the project remains bland.
- Analyst – (optional)
At this stage, it’s pointless to introduce something more complicated than a corkboard, 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 to determine what to test, who to test, how to test that audience, and how to interpret the results.
After direct testing, the product 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 “Finish” stage is called Lead Time.
Here, you are seeing an example of a real board using Kaiten, an online platform for planning and managing tasks.
Organizing processes this way can work well for a long time since it allows you to quickly drive cards through the system. However, all good things come to an end, and in this case, this simplistic approach doesn’t work well in the next step that we are about to see.
1. Startup With a Good Product/Market Fit
when the value hypothesis is found, and you need to cut the product
I would consider a product to be a good fit if the value hypothesis- i.e. the assumption that there is a need for the product and the product can solve that need – is found. Now that the hypothesis part is over, it’s time for you to cut the product.
The startup has found its niche, and the values that users will pay for that product. Now the product needs to be codified and developed. If the Product Manager can test ten hypotheses per week, then the developer can fill in only one task per week (conditional numbers). 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? More specifically, how do we ensure that the development operations are in sync with the product operations?
The most common way of solving this problem is to create a general list of tasks, also called the “backlog”. Product managers throw a bunch of tasks on this list, and developers take turns completing them.
The problem is that the Scrum methodology does not explain which of these tasks to do first. And this problem reaches its peak when the product starts having users.
2. The Product Has Users, and Their Number Is Growing
When there is a core group of regular users, and retention has started to plateau, problems begin to arise. This is because after the product is launched, 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 reorganize the architecture. If this is not done, the product will fall apart within a couple of months.
All this leads to hundreds of tasks in the backlog, and it is completely unclear which one should be completed first.
Well, how do we know what to start with?
The first thing you can try to do is break the backlog into three parts. This visually simplifies the task, but if the team has 200 tasks in total, and they physically only manage to do ten in a week, then there’s a 100 percent chance they will never get to all of 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 generally change and go another way.
Let’s resort to the Kanban method. It states that you need to enter limits on the maximum number of tasks on 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: “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. Developers are not intentionally looking for ways not to benefit a product. On the contrary, developers, as a rule, want to offer a bunch of ideas for the product development process, and are ready to implement them (if your situation is wrong, then your problems are much more serious than the organization of processes).
The Developer Factor
Developers may want to rewrite architecture 100% of the time in two cases:
- 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 if that isn’t done. For example, 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 their plans continued to grow, the losses from system failures grew exponentially as well.
- Developers do not understand why this task is needed, or its use. Unfortunately, not all Product Managers are ready to follow the example of Dmitry Potapenko, one of the owners of the Pyaterochka network. Once a week, Dmitry works at one of his stores to personally see the faces, moods, interests and problems of the customers. 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 they understand why the task is necessary.
This ensures that you start treating your developers on equal footing, as adults, and as independent and responsible people.
To fix this rule at the system level of the product development process, you need to create another board for products with the stages: Design, Sale, and Solution. Due to the fact that the Product Managers will greatly save time on senseless prioritization, they will free up time on “selling” the tasks to developers. If developers understand that this task will bring two times the growth, or that all users have waited for 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/her to cope with difficulties.
Of course, at first it will be difficult to work under the new rules. To ease the burden of the developer’s responsibility, the Kanban method suggests introducing (yes, another limitation) a fixed ratio of tasks in the work from each list.
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 since 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, 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 work” and “Finish”. The lead time department always has their attention, 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. Product Managers can insert a developer’s 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 to not overload the space of directors, Kaiten allows you to place simplified product boards.
Benefits of Using Kaiten in Your Product Development Process
Thanks to an end-to-end tasking system, Product Managers 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 customer deadlines.
Looking at the graphic below, we can say that the received task with a probability of 50% will be completed in four days and with a probability of 85% in 12 days. You no 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 three categories:
- We’ll do it for sure
- We’ll probably be on time
- If there is extra time left, we’ll get to it
This gives an understanding of what to expect from the new version and eliminates the 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 with Kanban. If you want to try Kaiten, go to https://kaiten.ru and write to our support contact: “I want to live. 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!
We would like to thank Andre Remati, Product and Marketing Manager at EPAM Systems, for this article.
