About spacecraft and space. How to make a feature by changing the entire product along the way
On April 24, an important change occurred in the Wrike platform: the team announced the public release of a new feature - “Spaces”, in the Russian version - “Spaces”.
The goal of Spaces is to improve the work of teams in the task manager and simplify navigation in the product, making the processes more organic and transparent. Did we do it? Keep reading and learn how to roll out serious updates in a large company and not screw it up, how to ensure the interaction of 30 scrum teams and what lessons we learned from the product development process, the release of whichlater cost us a lot of blood and a breakthrough team spirit.
Why were Spaces invented?
When Wrike was created, it was focused on solving the problems of the effectiveness of small teams of 15-20 people. It is convenient for such teams to work in one place where there is a “space” for everyone.
Over time, the size of accounts has increased multiple times. Now the product is used by distributed teams in accounts with thousands of people, and in the future we see Wrike as a convenient tool for the work of many departments of the company: on the one hand, working in different processes, on the other - still having to interact with each other.
Since in the real world teams exist in different offices, offices, countries, the Wrike team thought about creating a special space for them so that they could simultaneously work as part of their process and not lose touch with other departments.
Spaces allow individual workgroups to efficiently organize their workflow: give them the tools and data structure they need, access to various forms of queries, so that they can organize their own workspace and act more focused. Spaces also allow you to better control the distribution of information in multi-functional teams and increase the level of data security.
The idea of creating Spaces belongs to Sasha Plotvinov and Van Saveliev, Wrike product managers. First, they conducted research, drew a prototype of the solution for the teams on the board, assembled mock-ups and validated the idea. Later, it was finalized at the Wrike Hackathon , where they took a step to the side and assembled a Personal Space prototype that complemented the concept.
“Spaces” is, first of all, a feature for teams. However, it is based on the concept of living personal space, which everyone needs to exclude unnecessary information and extraneous noise.
What problems do Spaces solve?
To simplify, Wrike consists of projects and tools for working with them. For example, when working on a comprehensive release, you create a number of projects, monitor their progress through the Gantt chart, control the loading of teams using Workload, and, based on the results, create a report for stakeholders.
Everything seems to be simple, but if you have thousands of people working in one account in a large number of teams with overlapping processes and using many tools, then two problems appear: it becomes difficult to manage processes andthe user interface is overloaded with unnecessary elements .
there
were
Such obstacles to effective teamwork arise for a number of reasons: firstly, in the same tree of folders there are many teams; the user constantly sees irrelevant information and inadvertently violates the structure of the “alien” team. Secondly, only administrators have access to process management, and the account structure is often formed by the chief manager-administrators.
In the process of developing Spaces, we came to two key tasks:
Wrike is one of those companies that believe that horizontal management outperforms vertical and “turquoise” organizations show themselves in the most efficient way. The approach implemented in Spaces will help the team reach a new level of transparency and self-organization, where horizontal management will prevail.
- Ivan Savelyev, Wrike Product Manager
What difficulties did we encounter?
Of course, significant changes in the product entail great risks and a number of difficulties. Here are some of them:
Difficulty 1. To mitigate risks
Adapting an account to a new way of organizing work is a rather laborious task. Inside Wrike, the problem was discovered almost immediately: as a company with many teams and processes, we fall into the category of customers whom we consider our own audience and use our product daily. Inside the team account (more than 800 people from all international offices), we launched releases and immediately received feedback from the inside - this helped to prepare for a public release and maximize risks in advance.
For those who have never used Wrike, in the initial stages we conducted a series of solution interviews, launched testing using the serviceUserTesting , and also made an early access program for Spaces functionality for interested customers.
Before launching to the entire audience, we also conducted A / B testing on new trials to make sure that the new navigation paradigm is intuitive for new users. From testing it became clear that new users are successfully starting to use the product. We also interviewed the test and control groups and found that among the respondents, users were much more likely to talk about the understandability of the interface and the ease of use of Wrike.
Difficulty 2. Bring the value of the solution to the client
. Wrike has many clients who already use the service and have set up their work processes, so there was a risk that the new functionality would be reluctant.
We launched private beta for key clients and connected our Professional Services department to the process .
In order to convey the problem, and, subsequently, its solution to customers, Customer Success managers together with account administrators identified the problems of organizing processes at an early stage and told customers how Spaces could solve them. Thus, we transmitted the maximum value of Spaces, which outweighed the size of the costs of the restructuring. We didn’t just suddenly “roll out the feature”, but systematically prepared customers for its appearance: Customer Success managers conducted webinars, taught customers how to navigate new features, did training email newsletters, and talked about best practices.
Later, we did not make any calls at all: clients began to come to the early testing program themselves and use a new feature.
Difficulty 3. One improvement requires many changes. A
platform improvement affects various aspects of the product, and we decided to undertake modernization in order not to stand in one place. We were lucky with a development team that untied the most incredible technical nodes and found optimal solutions throughout the work on the project. In addition, everyone understood the need for this initiative, so we always had strong support from VP and CEO.
From the very beginning, the development team decided to create a minimally connected architecture, turning the entire solution into a set of separate business components and mini-applications that integrate and interact only among Workspace (the final product that the Wrike user sees).
A separate repository was created for these components, including a sandbox. It was possible not only to look at each component in action and show it, for example, in a sprint review, but also to conduct its full-fledged development and testing. Assembly, unit test runs and autotests took an order of magnitude less time than when developing in a full-fledged Workspace. This allowed developers to quickly iterate, showing the results at the end of each sprint, and, if necessary, quickly make changes to both the functionality and the API. After some time, the next step was taken - the creation of a kind of “playground”, on which a very simplified interface of the main product was created, including the integration of most components. This allowed us to design and debug their interaction with each other.
How did the teams interact with each other?
Wrike has about 30 scrum teams working on their part of the product, each of which is currently affected by features, or will be included in the process in the near future. The issue of inter-team interaction during the development of Spaces sometimes arose very sharply - after all, each team has its own product OKRs for the quarter.
The issue of communication was a priority: where it was possible to discuss everything in advance, to agree and formalize the agreements, the interaction turned out to be better than with those teams with which there were no preliminary discussions. In the latter case, the development team had to make changes or modify someone else’s functional themselves.
- Alexey Kartavenko, Frontend Teamlead The
number of problems that arise when 30 teams interact with each other in a very intense agile environment should not be discouraging. For almost any company, arranging a scrum process is already an achievement, and scrum of scrums is a fantasy: here product-owers, leads, and ordinary developers must learn how to work with each other.
These are the tips given by the Spaces team to those preparing to make a big project:
The goal of Spaces is to improve the work of teams in the task manager and simplify navigation in the product, making the processes more organic and transparent. Did we do it? Keep reading and learn how to roll out serious updates in a large company and not screw it up, how to ensure the interaction of 30 scrum teams and what lessons we learned from the product development process, the release of which
Why were Spaces invented?
When Wrike was created, it was focused on solving the problems of the effectiveness of small teams of 15-20 people. It is convenient for such teams to work in one place where there is a “space” for everyone.
Over time, the size of accounts has increased multiple times. Now the product is used by distributed teams in accounts with thousands of people, and in the future we see Wrike as a convenient tool for the work of many departments of the company: on the one hand, working in different processes, on the other - still having to interact with each other.
Since in the real world teams exist in different offices, offices, countries, the Wrike team thought about creating a special space for them so that they could simultaneously work as part of their process and not lose touch with other departments.
Spaces allow individual workgroups to efficiently organize their workflow: give them the tools and data structure they need, access to various forms of queries, so that they can organize their own workspace and act more focused. Spaces also allow you to better control the distribution of information in multi-functional teams and increase the level of data security.
The idea of creating Spaces belongs to Sasha Plotvinov and Van Saveliev, Wrike product managers. First, they conducted research, drew a prototype of the solution for the teams on the board, assembled mock-ups and validated the idea. Later, it was finalized at the Wrike Hackathon , where they took a step to the side and assembled a Personal Space prototype that complemented the concept.
“Spaces” is, first of all, a feature for teams. However, it is based on the concept of living personal space, which everyone needs to exclude unnecessary information and extraneous noise.
What problems do Spaces solve?
To simplify, Wrike consists of projects and tools for working with them. For example, when working on a comprehensive release, you create a number of projects, monitor their progress through the Gantt chart, control the loading of teams using Workload, and, based on the results, create a report for stakeholders.
Everything seems to be simple, but if you have thousands of people working in one account in a large number of teams with overlapping processes and using many tools, then two problems appear: it becomes difficult to manage processes andthe user interface is overloaded with unnecessary elements .
there
were
Such obstacles to effective teamwork arise for a number of reasons: firstly, in the same tree of folders there are many teams; the user constantly sees irrelevant information and inadvertently violates the structure of the “alien” team. Secondly, only administrators have access to process management, and the account structure is often formed by the chief manager-administrators.
In the process of developing Spaces, we came to two key tasks:
- The user should see only what is relevant to him
- Delegation and self-organization should come to the place of vertical management
Wrike is one of those companies that believe that horizontal management outperforms vertical and “turquoise” organizations show themselves in the most efficient way. The approach implemented in Spaces will help the team reach a new level of transparency and self-organization, where horizontal management will prevail.
“If before the account administrator had a high degree of responsibility for the processes, now he will be able to entrust the organization of the team’s workflow to his immediate supervisor, who often knows better the features of his team.”
- Ivan Savelyev, Wrike Product Manager
What difficulties did we encounter?
Of course, significant changes in the product entail great risks and a number of difficulties. Here are some of them:
Difficulty 1. To mitigate risks
Adapting an account to a new way of organizing work is a rather laborious task. Inside Wrike, the problem was discovered almost immediately: as a company with many teams and processes, we fall into the category of customers whom we consider our own audience and use our product daily. Inside the team account (more than 800 people from all international offices), we launched releases and immediately received feedback from the inside - this helped to prepare for a public release and maximize risks in advance.
For those who have never used Wrike, in the initial stages we conducted a series of solution interviews, launched testing using the serviceUserTesting , and also made an early access program for Spaces functionality for interested customers.
Before launching to the entire audience, we also conducted A / B testing on new trials to make sure that the new navigation paradigm is intuitive for new users. From testing it became clear that new users are successfully starting to use the product. We also interviewed the test and control groups and found that among the respondents, users were much more likely to talk about the understandability of the interface and the ease of use of Wrike.
Difficulty 2. Bring the value of the solution to the client
. Wrike has many clients who already use the service and have set up their work processes, so there was a risk that the new functionality would be reluctant.
We launched private beta for key clients and connected our Professional Services department to the process .
In order to convey the problem, and, subsequently, its solution to customers, Customer Success managers together with account administrators identified the problems of organizing processes at an early stage and told customers how Spaces could solve them. Thus, we transmitted the maximum value of Spaces, which outweighed the size of the costs of the restructuring. We didn’t just suddenly “roll out the feature”, but systematically prepared customers for its appearance: Customer Success managers conducted webinars, taught customers how to navigate new features, did training email newsletters, and talked about best practices.
Later, we did not make any calls at all: clients began to come to the early testing program themselves and use a new feature.
Difficulty 3. One improvement requires many changes. A
platform improvement affects various aspects of the product, and we decided to undertake modernization in order not to stand in one place. We were lucky with a development team that untied the most incredible technical nodes and found optimal solutions throughout the work on the project. In addition, everyone understood the need for this initiative, so we always had strong support from VP and CEO.
From the very beginning, the development team decided to create a minimally connected architecture, turning the entire solution into a set of separate business components and mini-applications that integrate and interact only among Workspace (the final product that the Wrike user sees).
A separate repository was created for these components, including a sandbox. It was possible not only to look at each component in action and show it, for example, in a sprint review, but also to conduct its full-fledged development and testing. Assembly, unit test runs and autotests took an order of magnitude less time than when developing in a full-fledged Workspace. This allowed developers to quickly iterate, showing the results at the end of each sprint, and, if necessary, quickly make changes to both the functionality and the API. After some time, the next step was taken - the creation of a kind of “playground”, on which a very simplified interface of the main product was created, including the integration of most components. This allowed us to design and debug their interaction with each other.
How did the teams interact with each other?
Wrike has about 30 scrum teams working on their part of the product, each of which is currently affected by features, or will be included in the process in the near future. The issue of inter-team interaction during the development of Spaces sometimes arose very sharply - after all, each team has its own product OKRs for the quarter.
The issue of communication was a priority: where it was possible to discuss everything in advance, to agree and formalize the agreements, the interaction turned out to be better than with those teams with which there were no preliminary discussions. In the latter case, the development team had to make changes or modify someone else’s functional themselves.
“There were extraordinary cases: once it was necessary to integrate a rather large and complex component developed by an external team before it was finished by this team (as a result, it appeared in our piece of functionality earlier than basically). What to do - we tried to finish the work as part of the deadlines and had to get out. And the time that we spent putting everything in order after the component was finished, we had to smear it with a thin layer when working on other features - the integration according to plan was long over! ”
- Alexey Kartavenko, Frontend Teamlead The
number of problems that arise when 30 teams interact with each other in a very intense agile environment should not be discouraging. For almost any company, arranging a scrum process is already an achievement, and scrum of scrums is a fantasy: here product-owers, leads, and ordinary developers must learn how to work with each other.
These are the tips given by the Spaces team to those preparing to make a big project:
- As often as possible, discuss the intermediate options of the project with different participants in the process, constantly collect feedback and look for additional food for thought.
- If what you do can be used internally (we were very lucky with this at Wrike), start a pilot project. Roll on everyone, inform everyone, run feedback forms!
- Determine the level of readiness at which you can enable functionality for loyal customers: among them there are always those who like to keep up with the times and activate all sorts of experimental features. Their feedback will be especially valuable because they are your target audience. all early testing mechanisms are at your disposal: A / B experiments, limited and controlled rollouts of alpha and beta versions, Early Access access on demand, etc.
- Balance between the speed of development and its quality, as on a surfboard: do not be afraid to leave technical debt in the current sprint, but immediately start tasks to eliminate it as soon as the situation becomes clear. Remember to give these tasks the highest priority. It is not short-sighted to do full coverage of unit- and auto-tests of functional that can change after feedback in the next sprint. Moreover, it’s not just stupid, but criminal for the engineer to leave the junk code in the end and let it get to the release.
- Try to properly prepare for each next sprint: conduct PBRs (Product Backlog Refinement), be sure to take tasks in the current sprint to research what you plan to do in the next, talk with Product Owner and the UX designer as much as you see fit: pursue them in the kitchen and in the smoking room, clarifying the details. Try to synchronize the backend, frontend and testing in such a way that the interaction is “overlapping”, so that no one is idle, waiting for the readiness of colleagues of another specialization, so that you don’t have to sit on the mok and then throw them away, etc.
- Closer to the release date, when passions are heating up and the bulk of the work is being transferred from developers to QA engineers, substitute your shoulder for them: test your code yourself, run regression, help with parsing, and try to write autotests.
- When interacting with other teams, start regular discussions in advance about how exactly you will do this. Write down all agreements and plans, generate documentation, you can even draw up contracts - not because someone will try to deceive you and not do too much, but because everyone has their own foam of days and your problems are only five percent alien. Sprint synchronization is ideal; aim for it.
- When using something developed by other teams, be wary of statements that "almost everything is ready, take and integrate." First, you’ll have to find out if you don’t want to get into a mess, blindly taking what they give and building your plans on it (especially calendar ones).
- And most importantly: not a single serious thing in a complex IT world is done at the click of a finger, therefore, if the project is in development for a long time and they begin to “look sideways”, take care of your nerves and know: even if not today, but tomorrow or the day after tomorrow, endlessly slipping threads will intertwine, the fog will scatter and success awaits you - you believe in what you are doing, right?