On Spaceships and Spaces: How to Introduce a New Feature and Transform Your Product

On April 24, Wrike announced a public release of a new feature titled Spaces. The ultimate goal of Spaces is to improve teamwork in the task manager and to make navigation inside the product more elegant and easy-to-use, thus making processes more organic and transparent. Read on to learn how to roll out major updates in a big company easily, how to engage and connect 30 Scrum Teams, and what lessons we learned while developing this product. This release required a lot of blood, sweat, and tears, but boosted our team spirit.

Why we invented Spaces

At the dawn of Wrike, the idea was to solve efficiency challenges for small teams of 15 to 20. These teams usually feel comfortable under a single roof where there is a place for everyone.

Accounts have grown exponentially over time. Now the product helps distributed teams with 1000+ user accounts. Looking forward, we see Wrike as a convenient tool for multiple corporate departments who work on separate processes but still need to cooperate and communicate with others.

In real life, teams function in their own rooms, offices, buildings and countries, so we at Wrike wanted to create a personal space for such teams where they could work together at the same time without losing touch with other departments.

Spaces is a great opportunity for individual work groups to tweak their workflow; it gives them all relevant tools and data structure, access to a variety of request forms so that they can organize their private work space for a more focused activity. Spaces enable multifunctional teams to better control the dissemination of information and ensure better data security.

Alex Plotvinov and Ivan Saveliev, Wrike Product Managers, are the men behind Spaces. First, they ran a research, drew a prototype of a solution for teams on a whiteboard, made mockups, and validated the idea. Later the idea was fine tuned and polished at the Wrike Hackathon. The Hackathon participants applied lateral thinking to the original idea to assemble a Personal Space prototype and completed the concept.

Spaces is, first and foremost, a feature for teams. However, it is based on the notion of a vital personal space which everyone needs to shut out excess information and background noise.

What problems Spaces solve

To make matters simple, Wrike comprises projects and gives you tools for working on these projects. For example, when you are working on a complex release, you can create a number of projects, use a Gantt chart to follow their progress, monitor the workload of the teams using the Workload tool, and compile a report for stakeholders based on the results.

It seems quite simple, however, if you have an account for multiple teams with thousands of users, where processes overlap and many tools are used at the same time, you have two urgent challenges on hand: it gets difficult to control and manage processes, and user interface is cluttered with elements.

before

after

There are several reasons why these obstacles hinder effective teamwork: firstly, there are multiple teams in the same folder tree, so users always have irrelevant information in front of them and can disrupt the structure of another team by accident. Secondly, only admins have access to process control. Often it’s senior admins who are in charge of account structure.

“Before, the account admin had a great share of responsibility for processes, but now admins can delegate team-specific process organization to team leads who often know much better how their teams function”.

— Ivan Saveliev, Wrike Product Manager

What challenges we faced

Naturally, such fundamental shifts in the product bring about major risks and a number of challenges to overcome, including:

Challenge 1. Mitigate risks

It is quite a task to adapt the account for a new way of organizing your workflow. Inside Wrike, the issue was identified almost immediately: being a multi-team and multi-process company, we fall into the category of our target audience and use our own product daily. We launched releases inside the team account (800+ users from all international offices) to get immediate feedback from the inside. It helped us to prepare for a public release and mitigate most of the risks in advance.

To address the needs of newcomers to Wrike, we ran a series of solution interviews, launched a testing session in UserTesting, and made available an early access program for customers who were willing to see Spaces in action.

Before scaling the launch to the entire audience, we ran A/B tests on new trials to make sure that the new navigation paradigm is intuitive to new users. Tests made it clear that new users were starting to use the product quite successfully. We surveyed a test group and a control group, and we found out that more people thought that Wrike was easy to use and the interface was user-friendly.

Challenge 2. Make customers see value in the solution

Many Wrike customers have already been using the service for some time and have their processes configured, so there was a risk that the new functionality would get a lukewarm welcome.

We launched a private beta for key customers and invited our Professional Services department to join the process.

To raise awareness about the challenge and its solution to the customers, our Customer Success managers joined forces with account admins to identify process organization issues at the earliest stage and to explain to customers how Spaces can solve them. Thus we managed to communicate the maximum value of Spaces that far outweighed the resulting upgrade costs. We didn’t just “roll out a feature”, we took care to get our customers ready to the new arrival. Customer Success managers conducted webinars, helped customers familiarize themselves with the new functionality, sent out newsletters with useful tips, and briefed customers about best practices.

Further on, we didn’t have to make any further calls for action: our customers joined our early testing program on their own accord and started using the new feature.

Challenge 3. A single improvement requires a series of changes

Platform improvement deals with the product in its diverse aspects, so we decided to take on modernization so as not to stay long in one place. We are incredibly lucky to have a developer team capable of untying even the trickiest technical knots and finding the best solutions throughout the project. Moreover, everyone bought in the initiative, therefore, we were always strongly supported by our VP and CEO.

Right from the get-go, the developer team settled for a minimalist architecture where the whole solution would be a kit of individual business components and mini apps that can integrate and interact with each other only in Workspace (the end product visible to the Wrike user).

A separate repository with an integrated sandbox was created specifically for these components. One could use it to see each component in action and to demonstrate it, for example, during a sprint review, but also to run full-fledged development and testing of each such component. Assembly, unit test runs and autotest runs took just a fraction of the time it would take if the development was run in a full-blown Workspace. That made it possible for the developers to iterate quickly, showing results at the end of each sprint, and to make changes to the functionality and the API on the fly, if required. Sometime later the next step was taken — we built a so-called “playground” where we launched a simplified barebone interface of the main product with most of the components integrated. That helped us design and debug these components and how they interact with each other.

We came down to two key tasks when we were developing Spaces:

• Only those items that are relevant for a specific user must be visible to him/her
• Vertical management must be replaced by delegation and self-organization

Wrike is one of the companies that believe that horizontal management is ahead of vertical management and that teal organizations are proven to be the most effective. The approach we successfully implemented in Spaces will help our clients’ teams move to a new level of transparency and self-organization where horizontal management prevails.

How teams interacted with each other

Wrike has about 30 Scrum Teams who work on their own portions of the product. Each of these portions is either covered by the feature now or will be included in the process in near future. Sometimes, during the development of Spaces, interaction between teams really became an issue — no wonder, as each team has to meet its product OKRs at the end of each quarter.

Communication was a priority: interaction was always better with the teams who were able to discuss everything beforehand, negotiate and formalize their agreement, than with the teams who didn’t engage in preliminary discussions. In the latter case, the developer team had to make edits on their own or tweak the functionality made by other teams.

“There were some extraordinary cases: once we had to integrate a large and complex component that a third-party team had developed, but we had to do it before that team finished it (at the end of the day, it was in our portion of the functionality before it appeared in the main functionality). We couldn’t help it, but we tried to complete our work before deadlines hit, so we had to improvise. And we also had to distribute the time it took us to correct everything after the component was finished and spread it thinly on top of other features, because the integration was over long time ago, according to the plan!”

— Alexey Kartavenko, Frontend Teamlead

You shouldn’t be discouraged by a number of issues that emerge when 30 teams integrate in a very intense agile environment. A well-adjusted scrum process is a big win for any team, while scrum of scrums is an incredible achievement: there you have product owners, leads, and rank-and-file developments who have to learn to work together.

The Spaces team would like to share some of its experience with those who are getting ready to take on an ambitious project:

1. Discuss the intermediate versions of the projects with various participants as often as you can, keep collecting feedback and try to discover more food for thought.
2. If the thing that you are working on can be used inside the company (we at Wrike are very lucky to have it), launch a pilot project. Then roll it out to everyone, send notifications, mail out feedback forms!
3. Determine what completion percentage will be enough for you to give the functionality to loyal customers. There are always those who like to be on the cutting edge and activate experimental features. They give the most valuable feedback, because they are your target audience. There is a wealth of early testing solutions at your disposal: A/B tests, limited and controlled alpha and beta rollouts, Early Access by request, etc.
4. Keep your balance between the speed and quality of development, like on a surfboard: don’t be afraid to have a technical debt in your current sprint, but make a task to eliminate it as soon as the coast is clear. Don’t forget to assign these tasks top priority. It would be unwise to cover with unit tests and autotests the functionality that may change as soon as the next sprint, following feedback. And it would be particularly unwise, even criminally stupid, for an engineer to leave junk code and allow it to sneak into the release.
5. Make every effort to get ready for the next sprint: conduct PBRs (Product Backlog Refinements), take on assignments to research your future tasks in the current sprint, talk to the Product Owner and UX designer as much as you need: don’t be shy, follow them to the kitchen or the smoking lounge and make every tiny detail clear. Try and synchronize the backend, frontend and testing teams so that the interaction processes overlap. In this way, no one will be on standby, waiting for their colleagues to finish their part of the task, no one will be left to tinker with mockups, only to throw them away later, etc.
6. As you move closer to the release date, when tempers flare and most of the work falls from the developers to QA engineers, support them: test your own code, run regression, help them with analysis, try to write autotests.
7. Interact with other teams, schedule detailed discussions of what you’re going to do at the very beginning. Keep track of all your agreements and plans, and generate documents. It is a good idea to make contracts — it’s not that someone will try to cheat and avoid doing extra work, it’s because everyone has so much on their plate already, and only 5% of your problems depend on the others. Synchronization by sprints is an ideal option, and that should be your goal.
8. When you have to use solutions developed by other teams, be careful of the phrases like “we’re almost finished, take it and integrate it”. You have to make clear every detail, if you don’t want to put yourself in an awkward situation, when you trust blindly in what other people give you and make your plans (and set your deadlines) accordingly.
9. We saved the most important thing for the last: the IT world is complex, and no major project can be finished in a snap. So, if your project is being developed seemingly for ages and people are giving you pointed looks, spare your nerves and keep in mind that those threads that endlessly slip away from you will form a pattern one day — not today, but maybe tomorrow or the day after tomorrow — the mist will rise, and you will be victorious. Because you believe in what you do, don’t you?