Michael Dubakov Blog

2 weeks ago

How we (un)plan the future

We have made some huge changes in our prioritization and planning process this year. In a nutshell, we have switched to open allocation. Here is the story.

Old way: boards, feature ranking, top-down approach

During the last several years we used to have a Product Board. This was a committee that focused on annual product plans. It consisted of up to a dozen people with various roles from sales to developers. We discussed our product strategy and set high-level goals (like "increase the market share at the enterprise market"). We created a ranking model that we used to prioritize features and create roadmaps:

Features ranking model

It kinda worked, but at some point I understood that somehow we pushed more and more features into Targetprocess, making it even more complex and heavy. Many people inside the company were not happy with this direction and they did not believe in it. Large customers demanded complex features like more flexible teams management, people allocation, an advanced QA area, etc. These are all good features, but we, as a company, somehow lost the feeling of end-user experience. Some simple things like search, navigation, performance, and simplicity were buried under fancy new features. This year, we put an end to that approach.

We want to create a tool that is pleasant to use. A tool that boosts your productivity and is almost invisible. A tool that saves your time. To achieve this goal, we have to go back to the basics. We should fix and polish what we have in Targetprocess already (and we have a lot) and then move forward with care to create new modules and explore new possibilities.

We have disbanded the Product Board, removed feature prioritization, done away with the top-down approach to people/team allocation, and replaced it with a few quite simple rules.

New way: Product Owner, Initiatives, and Sources

The Product Owner sets a very high level strategic theme for the next 1-2 years. Our current theme is very simple to grasp:

Focus on pains and misfits

Basically, we want to do anything that reduces complexity, simplifies basic scenarios like finding information, improves performance, and fixes your pain points in our product.

This does not mean that we will not add new features. For example, the current email notification mechanism is really outdated, so we are going to replace it and implement in-app notifications. But, most likely, we will not add new major modules into Targetprocess in the near future. Again, we are focusing on existing users and their complaints.


Our people have virtually full freedom to start an Initiative that relates to the strategic theme. An Initiative is a project that has start/end dates, a defined scope and a defined team. It can be as short as 2 weeks with a single person in the team or as large as 3 months with 6-8 people in a team.

There are just three simple rules:

  1. Any person can start an Initiative. The Initiative should be approved by the Product Owner and the Technical Owner (we plan to use this approval mechanism for some time in order to check how the new approach goes). The Initiative should have a deadline defined by the Team.
  2. Any person can join any Initiative.
  3. Any person can leave an Initiative at any time.

Sources and Helpers

A Source is the person who started the Initiative. He or she assembles the team, defines the main problem the Initiatives aims to solve, and is fully responsible for the Initiative's success. The Source can make all final functional decisions, technical decisions, etc. (Remember, Helpers are free to leave the Initiative at any time, so there is a mechanism to control poor leadership).

A Helper is a person who joins an Initiative and is committed to help complete it by the agreed deadline. He or she should focus on the Initiative and make it happen.

The Initiative deadline day is pretty significant. Two things should happen on the deadline day:

  • The Source makes a company-wide demo. They show the results to the whole company and explain what the team has accomplished.
  • The Initiative should be live on production.

As you see, freedom meets responsibility here. People are free to start Initiatives and work on almost anything, but they have to meet their deadlines and deliver the defined scope. This creates significant peer pressure, since you don't want to show bad results during the demo.

This process was started in July. We still have a few teams finalizing old features, but the majority of developers are working in the Initiatives mode now. Here's a screenshot of the Initiatives currently in progress:

Initiatives timeline

The Initiatives in the Backlog are just markers; some of them will not go into development, and there is no priority here. Next is the Initiatives Kanban Board:

Initiatives Kanban Board

You may ask, how do we define what is most important? The answer is: it does not matter. If we have a real pain from customers, and we have a few people that really want to solve this problem — it will be solved. Nobody can dictate a roadmap, nobody can set priorities, even the Product Owner. The Product Owner can start their own Initiatives (if they can get enough Helpers) or decline some Initiatives (if it takes tooooo long or doesn't fit the strategic theme).

As a result, we don't have roadmaps at all. We don't discuss priorities. And we can't provide answers to your questions like "when will you have a better Git integration". We can only make promises about things already started (you can see some of them above). All the people inside our company care about making our customers happy with the product, and now they have been enabled with real power to react faster and help you.

We can also promise that Targetprocess will become easier, faster, and more useful with every new release.

1 year ago

Agile Software Development Process: 90 Months of Evolution

Three years ago I wrote an article that describes the changes in our Agile software development processes from 2008 to 2012. Three more years have passed by and our processes were not set in stone. Here I want to provide you with 90 months of changes in our product development practices, company culture, structure and engineering practices. Hope you will find it interesting and learn from our mistakes.

Read the article: Agile Software Development Process: 90 Months of Evolution

Teams structure evolution

1 year ago

Minimal Action Energy Principle in User Interface Design

In physics, there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. the path that demands the least energy.


When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate the efficiency of UI. This is the first try.

Let's say we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:

From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.

So what is energy? That is a very tricky question, even in physics. Luckily, humans are more simple, so we can define all the processes where we lose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that, we can compare the energy of user interfaces and find the one with the least amount of energy required to complete some action.

We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let's call it Action Units (au). All actions can be expressed via this unit:

1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up

If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. This means the user can actually spend more time with a system, but apply less energy to complete the tasks.

Let's calculate User Interface Action Energy for a simple login action:

login_energyLooking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn't highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au

This decomposition makes it clear where we have energy leaks! Let't fix it to spend less energy:

Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn't highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au

This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes: implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.

1_login_500px_miniLooking at the form: 1
Click the Facebook button: 1
Wait: 3
Total 5 au

The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for a few seconds most likely. So total the Action Energy will be around 2 au.

Time != Energy

Usability testing is not new and counting clicks is not new. Usually, we just measure the time to complete a task, observe bottlenecks, and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.

Moreover, a usability test doesn't give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.

The designer's job is to think. The user's job is to use the tool with ease.

Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.


I think we can automate action energy measurements. These days, we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory, it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.

For remote usability tests where we have limited access to a real person's data, we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.


  1. Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
  2. Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
  3. Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
  4. Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
Get started for free

Sync up your teams with a visual project management tool that adapts to your organization and gives you transparency across different projects and departments. Visualize every step of the way.

Get started