Open Prioritization Meeting

When I first visited Jimdo back in 2010, I saw a thing called “Team Wall” - a big wall painted in black, magnetic paint. The idea behind it was simply to use all the creativity of all the great people who work at Jimdo. So everyone who had an idea on how to improve the product, took a piece of paper, wrote down his suggestion, and attached it to the wall. This seemed to work out very well, because not long after starting, the wall was dotted with paper. However, what seemed to be a huge success, turned out to also yield a couple of problems. Many of the ideas hung on the wall for weeks or months - and many of them were never followed up at all. They were good, but did not fit within the business strategy. Or - they were good, but too many other ideas were even better. Nadja, the Flow Manager at Jimdo, often said: “This is not a black wall; It‘s a black hole!” This state created a lot of frustration. They were asked to share their ideas, but most of them were not pursued. And the reasons for this never became clear to them, so the idea wall was abolished again.

The team wall story is another example of a huge problem that occurs over and over again when companies create (or even just allow) big queues. These queues are almost always seen as a “place of unloading”, but without a common understanding of what happens to all the items after they are put in the queue. Furthermore, queues have this really annoying habit of growing and growing. So when items are not being removed, it becomes less and less likely that the things in the queue will ever be completed at all. The bigger the queue, the more effort it takes to manage it. This means that things will be overseen, duplicates sneak in, etc.

Queues lead to overburdening (stress, poor quality, frustration)

Jimdo’s experience with the team wall was one major reason for introducing a concept which they call Open Prioritization Meetings. The first team to start this meeting was the Feature Team, which is called “Captain Feature”. The mission of this team is to maintain and improve the Jimdo CMS, which is pretty much the core of the whole Jimdo application. Besides the end users, the Feature Team has a couple of internal customers: The Shop Team, the Payment Team, the Support Team, the Country Teams, etc. So, the Feature Team can also be seen as a service provider for their colleagues. This again led to a huge queue, although this time, a digital one. Over time the different teams had created tickets for each of their requests, and put them into the issue-tracking system. Very often, the expectation was: “Now that I have placed my order, I just have to wait until it is finished.” But the Feature Team’s capability was less than the overall demand. So the queue (in this case, it was called “Backlog”), grew and grew. And again: dissatisfaction was the result. The Feature Team wanted both to help their colleagues, and to build new features for the end users. This turned out to be impossible, and led to stress and frustration, aware that the queue was constantly growing. The other teams realized that their requests were not being processed, but there was no transparency with the reasons behind this. The Jimdo founders, yet another group of important stakeholders, couldn’t understand why it took so long to build new, strategic features.

Since introducing the Open-Prioritization-Meeting, many of these problems have been solved. This is how it works: On a bi-weekly basis, everyone who has a request for the Feature Team is invited to come to their room and bring his ticket(s). The different stakeholders then pitch their ticket, explaining why they think that this particular ticket has a high business value for the company, and should be done next. After this, the team, together with Fridtjof (one of the founders), decides which tickets they will accept for the next two weeks, and which ones they reject. The principle behind this meeting is: “Never make promises you can’t keep!” A prerequisite for this is that the team must know its capability: How many new tickets can they manage? How big can these tickets be?

The tickets that are not accepted at this time, are returned to the stakeholders immediately. Sometimes people are told: “Please come back with this request in 8 weeks.” And sometimes it is decided that a request won‘t be done at all. Of course it is frustrating for the person whose ticket is rejected - but it‘s better having this initial frustration, than having false hope that cannot be fulfilled. In that case, the frustration would kick in later - and much harder. The Open-Prioritization-Meetings ensure that there is no Backlog of stakeholder requests. In our experience, this is the best kind of expectation management!

And, by the way, the Open-Prioritization-Meeting usually only takes 30-45 minutes.

Although this format is quite new, we’re already seeing a couple of positive effects:

• The team’s capability is more visible. Now it’s possible to avoid overloading the team - and at the same time, measures are taken to increase the capability.
• Queues lead to stress. (“Look at all the work we have to finish! We can never do this!”) By abolishing the queue, the stress level decreased.
• During the meetings, the stakeholders communicate directly, as opposed to the ticket system before. This prevents misunderstandings and builds trust.
• The different teams have valuable discussions about what their most important request is, because they know that only 1-2 items will be accepted.
• Everyone who is present at the meeting learns the reasons why certain things are worked on, and others aren‘t. Fridtjof is forced to lay out the company strategy on a regular basis (“Your idea is good. But this year we want to focus on another target group. The reasons for this are X, Y and Z. So we won‘t do your thing this year.”) In this case, Open-Prioritization-Meeting is a means of educating the employees, with respect to understanding and improving the company strategy.
• In the duration of the meeting, there is an incredible amount of knowledge and experience from different disciplines gathered in this one room. So it‘s possible to find simple and creative solutions immediately: “I have an idea how we could do this with very little effort. Would you be satisfied with an 80% solution?” or “Can you do this by yourself, if we give you access to this system?”

The Feature Team was the first team to experiment with Open-Prioritization-Meetings. The positive outcomes have encouraged others to do a similar thing. Right now, more and more other teams are starting to figure out how this meeting should look in their environment.

This story is part of a free ebook about Jimdo which is called "Doing things differently. Leadership, Management and Alignment with Jimdo." You can download it here.


P.S. Eleven (!) years ago, Ron Jeffries wrote a blog post about what he calls "Petition the king" We did not know about this when we started the Open Prioritization Meeting, but both formats are very similar (unless there is no King at Jimdo:-)  Thanks, Yason Yip for pointing us to this! And as an answer to Ron‘s question in the last paragraph: "No, it‘s not madness!"
Read Ron Jeffries Post