After working with software development teams in various organizations ranging from small companies to holdings, it is always a pain to manage incoming requests. There are lots of different ways to design a demand management process but in this article, I will explain how we have achieved a simple yet effective way to prioritize and assign demands in Makswin.
According to Wikipedia definition of Demand Management is;
Demand management is a planning methodology used to forecast, plan for and manage the demand for products and services
While this writing is not academic nor definitive, it will show how we experienced a need and solved that it is an approved process in our company Makswin. First things first, if there is no cost of a good, people tend to buy more than they may need. They will buy it and consume as much as they can and there will be lots of waste🤮. So there needs to be a cost to creating a demand otherwise every single thought will be demanded from the technical team.
Before going in deep, I want to give some introduction about our departments in Makswin. Other than Sales, Finance, and Marketing we have our Product team which includes UI/UX designers.
Most Product teams don’t have UI/UX designers in them, usually IT departments have these kinds of roles. I personally don’t believe it is the best way. The reason is when the product team designs an experience they need to experience that first-hand through the product. When designers are in the IT team, it causes too much going back and forward, which slows down the whole process. After hours of debates, we have concluded that UI/UX is part of a product, not IT.
Whenever the product team requests something from IT, it could be either an e-mail, Slack message, Whatsapp message, or even a phone call at night. Also, there is a tendency to get instant technical feedback from IT. Even for a senior software developer, it is very risky to give any feedback based on what is read or heard a couple of minutes ago. This process could lead teams to dark places where everything is confused with something else.
For this reason, the first thing we did was to collect all of the demands in a list, this could be anything from Google Sheet to Trello. The only requirement is that this platform needs to be accessed by both parties. After selecting the correct platform now it is time to set some basic rules. Every demand has to answer some predefined questions. The reason for these questions is to point out the real need and priority of the demand. We require 4 questions to be answered for each demand before going into demand details. Try not to ask too many or too complicated questions. We want to determine the cost not kill the whole process.
Our questions in every demand include;
Purpose of the Request: Explain which problems will be prevented and/or what kind of gain/advantage will it provide to the company when your request is realized.
Current Status: Briefly describe the current situation that led to your request.
Lost Opportunity While Your Demand Is Not Fulfilled: Explain what kind of profit/advantage loss the company suffers every day that your request is not fulfilled.
Business Priority: What is the business priority. It can be Low, Medium, High, Urgent.
and that’s it 🙌.
With these 4 questions, the demand manager from IT can grasp the background and reason of the request. After these questions requester adds a detailed explanation and product designs to the demand (designs can be shared from Figma, Zeplin, etc.).
All of this effort of opening a demand shouldn’t be exhausting for the requester but it should take some time (time = cost) so that before opening a demand, the requester needs to think about whether there is a need or it is just a thought.
Every day demand manager checks for the new demands and analyzes them from the technical point of view. After analysis, she creates an Epic that will encapsulate all of the User Storys and sets a planned sprint and estimated effort in hours. Because the requester sees the same demand list after setting sprint and effort there can be meetings to clear some areas and maybe change the planned sprint according to priority and technical availability.
In this way, both parties can communicate according to a written document which eliminates most of the misinterpretations and minimizes the total effort of the whole process. With this process, we can assess and plan demands more efficiently.
After the demand starts to develop we have a couple of states. When a new demand is created by the product team its state is set to Ready for Technical Analysis. While the demand manager analyzes these demands she sets the state to In Technical Analysis. Technical Analysis can take from a couple of hours to a couple of days according to the complexity and additional information needed. When technical analysis is finished state becomes Ready For Development. In this state, demand’s planned sprint and estimated effort in hours are set.
In the development, the state becomes In Development/Testing, and finally, when demand is completed state is set to Released.
With the help of all of these states, the product team can follow the whole process of development and plan their roadmap according to it. After migrating to this process as Makswin we drastically minimized our product meetings and 1–1 calls between product owners and technical staff.
Hope some of the things we have written are helpful for you, if you have any comments don’t hesitate to share. 👌
