A case study: Launching a product process in a project-based company

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.

Goal

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.

Internal circumstances

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:

1. Client-driven customization

• 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.

2. Functional teams

• 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.

3. Decision-making pressure

• 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.

4. Developer influence

• 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 

• designing
• competencies required at different stages of the process

Step 4: Implement the new process across teams 

Step 5: Optimize the New Process

Step 1: Analyze the results of the existing 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.

Issues caused by the old process

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:

1. Some functions were implemented multiple times in the product.

Cause:

• Product owners and analysts don’t know the entire product. As a result, they may not realize that a feature already exists in the product and instead create it from scratch in a new location. Another problem-cause here is the product’s illogical structure. This makes it difficult for analysts to determine where it would be rational to implement a particular feature.

Possible “solution”: 

• Somehow increase product owners’ and analysts’ awareness of the product (through training, providing supporting materials, etc.).
• Implement features in a more intuitive and accessible way, so that product owners and analysts can easily understand where each feature should be placed in the interface and quickly identify if a feature already exists

2. Violation of validation rules (some features in the system could be used legally, although it contradicted the logic).

Cause:

• Low role of UX in the process due to excessive workload and being spread across various products for different users.
• A mockup is not a mandatory attribute of a user story passed to development.
• Low motivation for product owners and analysts to focus on the logic of new features. Instead, they integrate them into existing system elements, even in situations where a new editor, feature block, or product section is clearly needed.

Possible “Solution”:

• Increase the UX resource capacity.
• Stop spreading UX across diverse products. Instead, focus one UX specialist on a specific type of product (which can be defined by user criteria or front-office/back-office distinction).
• Involve UX in communication with development to ensure they advocate for their interests and prevent the reduction of product requirements at the expense of the user experience.

3. Opaque product structure (users couldn’t understand in which menu section they should search for key product features).

Cause:

• UX designer was distracted across many different products. As a result, they might simply forget how a feature was implemented previously, and there was no time to go back and check

Possible “Solution”:

• Similarly to the previous point.

4. Some key product features were unusable without a manual.

Cause:

• Over the years of the process, the product has become increasingly tangled. It’s hard to figure out, and users make mistakes

Possible “Solution”:

• Implement logic into the product structure.
• Separate product decision-making from product owners and analysts. Assign this responsibility to another specialist.

5. Not all new product features were described in the manual or reflected in marketing and supporting materials.

Cause:

• Lack of technical writers.
• Low level of control over the documentation of all features

Possible “Solution”:

• The process should allow for controlling these changes, making them more transparent to the product stakeholders.

Step 2: Establish quality criteria for the outcome of the new process

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:

1. Some functions were implemented multiple times in the product.

Cause:

• Product owners and analysts don’t know the entire product. As a result, they may not realize that a feature already exists in the product and instead create it from scratch in a new location. Another problem-cause here is the product’s illogical structure. This makes it difficult for analysts to determine where it would be rational to implement a particular feature.

Criteria:

• Only features that enhance the product’s value for users are passed to the development team. The team no longer spends resources on implementing functions that already exist in the product.

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.

2. Violation of validation rules (some features in the system could be used legally, although it contradicted the logic).

Cause:

• Low role of UX in the process due to excessive workload and being spread across various products for different users.
• A mockup is not a mandatory attribute of a user story passed to development.
• Low motivation for product owners and analysts to focus on the logic of new features. Instead, they integrate them into existing system elements, even in situations where a new editor, feature block, or product section is clearly needed.

Criteria:

• The user interface enables a marketer without prior experience to complete all user scenarios independently and protects users from errors. The product is easy to navigate, and implementing key scenarios does not require consulting the manual. All necessary and sufficient information is either contained within the interface or easily accessible from it.

Comment:

• Settings should not mislead the user. The value lies in the total cost of ownership, which includes, among other things:
• The user’s time spent correcting mistakes
• The user’s time spent studying the manual to use the product.

3. Opaque product structure (users couldn’t understand in which menu section they should search for key product features).

Cause:

• UX designer was distracted across many different products. As a result, they might simply forget how a feature was implemented previously, and there was no time to go back and check

Criteria:

• The user interface enables a marketer without prior experience to complete all user scenarios independently and protects users from errors. The product is easy to navigate, and implementing key scenarios does not require consulting the manual. All necessary and sufficient information is either contained within the interface or easily accessible from it.

Comment:

• Settings should not mislead the user. The value lies in the total cost of ownership, which includes, among other things:
• The user’s time spent correcting mistakes
• The user’s time spent studying the manual to use the product.

4. Some key product features were unusable without a manual.

Cause:

• Over the years of the process, the product has become increasingly tangled. It’s hard to figure out, and users make mistakes

Criteria:

• The user interface enables a marketer without prior experience to complete all user scenarios independently and protects users from errors. The product is easy to navigate, and implementing key scenarios does not require consulting the manual. All necessary and sufficient information is either contained within the interface or easily accessible from it.

Comment:

• Settings should not mislead the user. The value lies in the total cost of ownership, which includes, among other things:
• The user’s time spent correcting mistakes
• The user’s time spent studying the manual to use the product.

5. Not all new product features were described in the manual or reflected in marketing and supporting materials.

Cause:

• Lack of technical writers.
• Low level of control over the documentation of all features

Criteria:

• There are no undocumented features in the manual. All necessary and sufficient information to answer user questions is included in the documentation.

Step 3: Design the new process

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.

Enhancing the resolution of our process

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.

Product solution design

(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.

Mockup design

(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.

Product meeting

(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

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.

PBR (Product backlog refinement)

(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.

Post-processing

(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?

Competencies required at different stages of the process:

I settled on the following logic for distributing the stages of the process:

1. Request filtering

Skills and information needed to perform the stage: 

• It is important to understand whether the implementation of this feature brings potential risks or new opportunities for the product’s users. The full set of information, as well as the interest in its proper execution, is held either by the Head of Product or the PM

Position in the team: 

• Head of product

2. Product solution design 

Skills and information needed to perform the stage: 

• It is important to understand the specifics of the user’s work, the structure of the product, and the reasons behind the structure, to have contact with users, and to possess skills in eliminating uncertainty (research)

Position in the team: 

• Product manager

3. Mockup design

Skills and information needed to perform the stage: 

• It’s simple: to have skills in user research, prototyping, communication with clients, analyzing customer behavior, and so on

Position in the team: 

• UX/UI designer

4. Alignment of the product solution

Skills and information needed to perform the stage: 

• Be responsible for the entire product and the quality of product changes.

Position in the Team:

• Head of product

5. Help documentation update

Skills and information needed to perform the stage:  

• Describe new functionality in an accessible and clear way. Be familiar with the product description structure

Position in the Team:

• Technical writer

6. Marketing materials update 

Skills and information needed to perform the stage: 

• Understand the essence of the feature, know what value the user can gain from it, and be able to communicate the feature’s value to interested clients in business terms.

Position in the team: 

• Product manager 

Step 4: Implement the new process

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.

Step 5: Optimize the new process

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:

1. We abandoned the validation of the product solution as a mandatory stage of the process.

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:

• The time our users are willing to dedicate is a limited resource, as is the time of our employees. Our product is aimed at large companies with a large number of customers. The main research methods we use are prototype testing. However, three development teams implement changes in the product, which generates a considerable volume of changes. There is not enough time to test all the prototypes that our users are willing to dedicate to us. Similarly, our marketing department employees (we didn’t consider others, as they don’t fit the profile for our research) also lack the time.
• Validation of some features does not provide enough value to “invest” our users’ time into it. For example, if we are creating an editor for a new communication channel through messengers, and it does not differ from a previously added channel – another messenger, validation makes no sense, as no new issues arise. The old functionality is just repackaged under a new name.

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.

2. We abandoned the decomposition of the product solution before handing it over to development.

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.

3. We added a stage in Jira with a status for changes to marketing and commercial materials.

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.

Conclusions and results of process implementation 

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! 🙂

Read more great product management articles on Mind the Product

• Building for change: When transformation and product management meet
• Navigating the ‘us vs. them’ mindset in product management: Practical strategies
• Successful product management in companies where it’s least understood