Hi everyone! My name is Hermann Antonov, and I’m the Head of Product at CSI. We develop a CDP platform for marketing automation, targeting the retail market in Eastern Europe and Central Asia.
Three years ago, when I joined the company, it was undergoing a major transition — shifting from a project-based to a product-based approach. Previously, our customers were effectively the driving force behind changes to our products, while we acted as implementers. Now, everything had to change: we needed to learn how to design product changes deliberately to enhance its value and address the market segments we were aiming for.
The complexity of this transformation lay in balancing multiple approaches. As many of you may know (or have experienced in your companies), enterprise-level product users — our primary customer base — tend to customize products to their needs through their own budgets (SAP users, anyone?).
In this article, I’ll share my approach to transforming the core process — the product change process. This will be helpful for product managers who are navigating or preparing for similar transitions in their teams or companies. Please share in the comments how you would improve what I’ve done or approach things differently. I’d greatly appreciate constructive feedback and recommendations for valuable learning resources on this topic!
Let’s start by outlining the ultimate goal, the action plan, and the company’s initial state before the transformation.
Design and implement a process that enables controlled growth through new features, increasing user value while steering the product toward a state that allows us to penetrate our target market segments.
Every company has its unique characteristics, and ours is no exception. Here are some of these characteristics—or “constants,” as I call them. Our new process must account for these constants, as they are non-negotiable:
• We have commitments to clients to enhance the product based on their requests within reasonable limits (avoiding features that fall outside the product’s core purpose).
• We cannot completely stop responding to client requests. However, we can filter these requests using specific criteria and, for example, reject those that may harm the user experience.
• Certain product areas can be modified only by specific teams with accumulated expertise.
• While some teams can work across multiple areas of the product, no single team has expertise in all product areas.
• For a long time, key product decisions were made by analysts and product owners under constant pressure from clients regarding deadlines and costs.
• Deadlines and cost savings often came at the expense of interface quality and thorough analysis.
• Developers sometimes pushed for solutions that were more convenient for them but less user-friendly.
• Analysts and product owners, operating under deadline and cost pressure, prioritized developer preferences to reduce timelines and costs, often at the expense of the user experience.
Action Plan
Step 1: Analyze the results of the existing process
Step 2: Establish quality criteria for the new process
Step 3: Design the new process
Step 4: Implement the new process across teams
Step 5: Optimize the New Process
Let’s begin with an overview of the previous process, highlight the product issues caused by its inefficiencies, and identify specific root causes for each problem.
Previous process overview
1. A client submits a change request for the product.
2. The product owner or analyst writes the requirements in text form, shares them with the development team, and adjusts them to reduce implementation costs.
3. The product owner confirms the proposed implementation with the client.
4. The request is handed over to the development team for execution.
The product owner or analyst acted as the decision-making hub and the gatekeeper of the company’s interests when handling client-driven tasks.
1. Duplicate features: Some functionalities were implemented multiple times within the product.
2. Validation rule violations: Certain features could be used “legally” despite contradicting the logical flow of creating specific entities.
3. Opaque product structure: Users struggled to find key features within the menu sections.
4. Unusable features: Some core product features were impossible to use without a manual or direct assistance from the product team.
5. Incomplete documentation: New features were not fully reflected in product manuals, marketing materials, or supporting documentation.
After conducting the diagnosis, we identified the following root causes of the problems:
Cause:
Possible “solution”:
Cause:
Possible “Solution”:
Cause:
Possible “Solution”:
Cause:
Possible “Solution”:
Cause:
Possible “Solution”:
Based on the findings from the previous step, we outlined the value we wanted to achieve as the “output” of our new process.
I’ll be honest—there’s nothing groundbreaking here. But the fact remains: changes were regularly delivered into the product that violated fundamental principles of product development.
The new process needed to ensure this would no longer happen.
Here are the values we identified to serve as the foundation of our new process:
Cause:
Criteria:
Comment:
Every feature delivered by the development team should increase the product’s value. Re-implementing a feature does not add value but consumes the product team’s resources.
Cause:
Criteria:
Comment:
Cause:
Criteria:
Comment:
Cause:
Criteria:
Comment:
Cause:
Criteria:
Having established the core values, we began designing the new process. First, we outlined a high-level description of how work on new product changes would proceed. Here’s what we arrived at:
The logic was quite simple:
First, we essentially created two processes: one for features that can enhance the product or potentially harm the user experience, and the second for features that are unlikely to harm the user or enhance the product, essentially being custom improvements that don’t affect users (for example, plugin improvements specifically developed for a client and unavailable to others).
Secondly, there was a clear lack of post-processing steps after a feature was implemented. At this stage, marketing materials are filled out, technical documentation is added to the help section, instructions are prepared, and project documentation is updated (documentation with installation instructions and setup of the product’s main features).
The development processes were not changed. We simply gathered information from the developers on what materials or information were missing in the existing materials to make their work on the tasks more efficient and of better quality.
In the next stage, we outlined the key steps of the process in more detail and arrived at the following picture:
At the filtering stage, any task is directed to one of two streams. If the task is considered product-related, it is sent through what we call the “Product Stream.” If it is not considered product-related, it is directed to the “Project Stream.”
The product process stream is used for tasks that cannot be completed without involving the product team because the implementation is associated with risks to the users of our product. Of course, this criterion is not very specific. Therefore, the filtering is currently performed only by the product manager. Filtering by the product owner or, even more so, by the analyst will not achieve the desired result due to time and cost pressures from escalations.
The project stream is essentially the same as the process used earlier in the first part. The functionality design is carried out by the analyst and/or product owner. Tasks that the product manager does not see any risk to the users of the product can be sent through this stream.
Next, I will describe the steps of the product stream.
(Description of the textual part of US)
A responsible executor is assigned to the task — a product manager in charge of the corresponding part of the product where the changes are planned. Their responsibility is to determine how the solution will integrate into the product (which part requires modifications), what capabilities will be provided to the user, and what research needs to be conducted to make a well-informed decision.
A system analyst may also partially work on the solution in cases where the changes only affect the technical part of the product, which is outside the product manager’s expertise.
(Preparation of the layout)
Once all the necessary information has been gathered and all required research conducted, the product solution is handed over to the UX team for mockup design. The product manager may propose an interface solution (which usually emerges naturally during competitor analysis, customer feedback collection, and research). However, the UX team is not bound by this proposal.
(This is not shown on the diagram, but it’s the moment when complex product solutions face criticism from the team)
Once the initial mockups are ready (they don’t necessarily need to be highly polished for the next stage), the product solution is presented at a product meeting. A product meeting is where the product manager or analyst demonstrates the developed product solution and essentially defends it in front of the rest of the team. This ensures that every solution is subject to critique by the team. At this stage, issues or flaws in the product solution are often identified, after which it is sent back for refinement by the responsible product manager or analyst.
Alignment of the product solution is the point at which the product solution is considered fully finalized and ready for transfer to the development team. This approval is currently done by me, the Head of Product. I hope this is only a temporary stage needed during the transition period. Once the process matures, we should be able to trust the participants and avoid overseeing every product decision.
(Receiving feedback from developers)
At this stage, the analyst and product manager present the solution to the developers and answer their questions. Most PBR sessions proceed smoothly, but occasionally issues arise when the required solution cannot be fully implemented. In such cases, the product manager and analyst must compile a list of constraints preventing the initial product solution and consider these during a redesign. After revisions, the product solution is sent back to the product meeting stage.
This step has been the subject of much discussion within the team and with leaders of related areas. Designing a product solution is a substantial effort, which can be wasted if technical constraints ultimately block its implementation. However, we decided to retain the process as outlined. My reasoning is as follows:
• We’ve had meetings where product solutions were discussed with developers. These were not productive. Developers often proposed changes that either compromised user interests or duplicated ideas previously examined and reasonably rejected by the product manager.
• Developers are distanced from the users and business objectives. They often base their suggestions on technical considerations, aiming to provide the most efficient technical solution. However, this can lead to scenarios where an optimal technical solution becomes suboptimal for end users, hindering their ability to derive the product’s key value.
At the time of writing this article, I have not observed any critical issues stemming from technical constraints emerging at later stages of the process or from developers not influencing product decisions. Therefore, we continue to work according to this process.
This marks the end of the product-specific stage details. In fact, they conclude earlier. The project stream also includes PBR sessions, but I decided to highlight this aspect in my article because our approach may seem controversial to some. I’d love to hear about your experiences in the comments.
(Preparation of the technical specification, Making changes to project and commercial documentation)
By “post-processing,” we mean everything that happens with a task after it has been demonstrated during the demo.
Once development is complete, we need to carry out the following procedures:
• Add documentation describing the developed feature.
• Update project documentation to ensure the new feature is accounted for in the product installation process for clients, if it affects this process.
• Add information about the feature to commercial documentation (this includes marketing materials and internal documents prepared for sales managers about our product).
• Publish the feature on the demo environment.
This stage is straightforward and brief but is highlighted separately to ensure nothing is missed. 🙂
So, we have identified the key stages of the process. But who will execute them, and what competencies should the responsible individuals have?
I settled on the following logic for distributing the stages of the process:
Skills and information needed to perform the stage:
Position in the team:
Skills and information needed to perform the stage:
Position in the team:
Skills and information needed to perform the stage:
Position in the team:
Skills and information needed to perform the stage:
Position in the Team:
Skills and information needed to perform the stage:
Position in the Team:
Skills and information needed to perform the stage:
Position in the team:
We identified three steps to restructure the current situation and start working with the new process:
Team meeting
It was necessary to explain to the team what exactly we are addressing, what results we expect to achieve, and why we cannot stay with the current process from which we are moving away.
Adapt management tools
It was necessary to create a new board in Jira and our internal tools, as well as configure it so that the process would be transparent for all interested participants and external team.s
Optimize the process
It was clear that the process would not be perfect and would require “smoothing out” any rough edges.
The version of the process described above is close to the current one. This is already the 5th version of the process.
We do not have special measures to proactively identify process issues. This happens reactively, when any of the participants brings information about a problem or suggests changing the approach to solving a task at a particular stage. By the way, I just realized that it would be reasonable to communicate the possibility of process optimization to the team during the meeting. We didn’t do that, but it seems like it would have been useful :)
Here are a few examples of what we changed in the process and tools that help us keep it under control:
The version of the process described above is close to the current one. This is already the 5th version of the process.
We do not have special measures to proactively identify process issues. This happens reactively, when any of the participants brings information about a problem or suggests changing the approach to solving a task at a particular stage. By the way, I just realized that it would be reasonable to communicate the possibility of process optimization to the team during the meeting. We didn’t do that, but it seems like it would have been useful :)
Here are a few examples of what we changed in the process and tools that help us keep it under control:
Initially, we had planned a full-fledged stage in the process – the validation of the product solution. The goal of this stage was to ensure in practice that the product solution was sufficient to address the client’s needs, the interface was clear, and the user could implement the key scenario without significant problems or the need for much time spent on studying the documentation.
The reasons for abandoning the requirement for this step are as follows:
Based on these reasons, the following possible solutions were formulated:
• Reduce the number of tasks to be validated
• Increase the number of resources required for validation
We cannot increase the resources at the moment, although we are striving towards it. Therefore, we chose the first option. Now, the product manager independently decides what and how exactly should be tested before handing the task over to the development team. Typically, this applies to major changes, such as the introduction of a new editor or an entire module.
In cases where the initiator of the changes is the customer, it is not always possible to design only the required functionality. Often, a more extensive change to the product needs to be developed, which is then split into parts—one part is implemented as an enhancement, while others are part of product development (and often, not immediately, but much later).
At the same time, part of the process was done in a unified manner, but in the middle of the process, it was necessary to pause and split the task into several parts. One part would continue through the process stages, while the other would get stuck at one stage forever.
We decided to take a different approach and parallelized the process into several boards. One part goes through one board and ends with the preparation of the product solution at the final stage. Everything that follows after that stage goes to another board. The need for the “decomposition” stage disappeared.
Initially, we had one stage for post-processing the task. Since different people needed to make changes to different documents, we decided to add several stages aimed at assigning specific tasks to individual team members. This change is one of those that simplified our workflow but didn’t create significant problems.
After implementing the process, managing product changes has become easier. There are no longer tasks that would slip past product managers and only be discovered at the demo stage as changes with questionable quality.
However, new problems have emerged that we still need to resolve. There are still people on the team who find it quite easy and comfortable to work with the old process. Sometimes I encounter attempts at sabotage or low-quality design. This is not about product managers, but analysts or product owners (when they are involved in the process). We are also under pressure from clients on some tasks, as product design in the product process often takes more time than the quick one. This partly leads to not designing certain features.
There is also a priority issue. In the first place, the participants in the process are interested in priorities, and in the second place, external teams (such as sales managers, who directly interact with clients). We have not yet been able to make them transparent to all stakeholders. For some employees (product managers or UX designers), priorities are set manually in meetings with me. These meetings are held once a week, but now it seems to me that meetings every two weeks would be enough.
Let me remind you, our initial goal was: To design and implement a process that would allow us to incrementally add new features that increase user value and move the product toward a state that would allow us to enter target market segments.
Today, I can confidently say that we have achieved our goal. Since the process was launched, the base of active users on our platform has been steadily and predictably growing, and today we are again undergoing a period of transformation. But not of the process, but of the structure, as the current one no longer meets the growing demands of our team to quickly conquer the global domination in the field of marketing automation platforms. :)
That’s all for now. If you have had a similar experience and faced the same issues I did, please share in the comments how you ultimately solved them.
And if you recommend any articles, frameworks, or books about solutions to these problems, I would be very grateful.
See you! :)
Comments
Join the community
Sign up for free to share your thoughts