Automations - Transfer ownership         

Company: Pipedrive
Feature: Ability to transfer automation from one user to another. The customers highly requested this feature to boost team collaboration and user off-boarding from the software.
My role: I worked as a Product designer to deliver the whole solution and collaborated with different stakeholders from the start to the end of the project.
Objective of the case study: To highlight the power of collaboration and solving the pain problems of the customer in a short period by using an agile approach and quick experimentation.

The project contains detailed research and design docs that can be shared upon request.

About the project

What:
Solve user needs around transferring automation from one user to another with a fully functioning, baseline solution of changing the ownership of automation.

Why:
The most common reasons why customers reach out with a request to transfer ownership are the following:

  • The main requests are to transfer all automation from user X to user Y.

  • In some cases, tech-savvy users set up automation for their colleagues, and later request a transfer.

How:
By providing an option for the admin users to transfer the automation ownership from one user to another one.


High-level Process board

The overall project was quick, and the mission's objective is to solve the needs quickly as the problem statement was straightforward from the users and support team and required quick action from the team.

  • We kicked off the discovery phase similar to any other mission but realized quickly during the defining phase that the solution could be delivered earlier than the expected scope.

  • We decided to have a three days hackathon to deliver the working MVP where the whole tribe will work closely.

  • The hackathon was a success for the whole team and was later introduced as a part of the process on the company level.

  • To ship the feature successfully to the end user, we had a 3-week of follow-up mission to iterate and give the final touch to the MVP.


Backstory and timeline

Transfer of automation ownership was part of the 2023 concept ā€œautomation for teamsā€ that the team drafted in 2022 and we started preparing the research for the concept in Feb 2023.

  • Concept contained 2 important features to enhance the collaboration for the teams. Sharing and transferring automation to other users is the main highlight of the concept.

  • I worked in the research phase along with the PM and conducted user interviews and ran several workshops with the tribe.

  • Later we decided to split the scope into 2 parts, one for sharing feature and another for the transfer ownership feature.


User interviews and analysis

We conducted 10 interviews with users all across the globe and tested the wireframe to get the initial insights and test the assumptions. Interviews were conducted by PM, designer and engineers. I took the lead in some of the interviews and created the working prototypes for the interviews.

These interviews helped us to get on the same page with the users and empathize with their pain problems. Later we decided to change the entry point for the transfer of ownership as they mentioned using it as a separate feature from sharing, and they would like to have it in the list view of the automation. These interviews and insights changed the concept's scope and allowed us to work in 2 different teams.

We diverged, and one of the teams with 1 designer, 1 PM and 4 developers worked on the transfer of ownership and another team with the same set of resources worked on sharing the topic.


Challenges and team work

When we were deciding on the yearly roadmap and concept scoping, we got sudden pressure from the management to work quickly on the release plan and deliver the feature in a month. You can see the pain and request from the userā€™s end in the intercom chats.

Later we decided to work on the transfers ownership focused quick ideation session and started preparing for the hackathon. A bit about the hackathon:
Day-1: Team breakfast + setting the mood > Team call with customers/ partners to understand their pains/needs > Product-led session: interview analysis, competitors, risks and designs >Split the team>Hack > Check-ins.
Day-2: Check-in > Hack>Hack>Hack> Check-in
Day-3: Check-in> Iterations and product led session> Hack>Hack> Final check-in> Demo


Scoping and stories

I started moving quickly and defined the scope of the hackathon and the main user stories we needed to tackle for quick wins.

There were plenty of hurdles from the engineering side, and we eliminated a few items from the scope and delivered the working MVP by the end of the hackathon.

After a gap of a week, we kicked off a follow-up mission, and I took the lead from the design side and iterated the flows and conducted a quick design review session with the extended design team and mission team.


Weekly rituals during the mission


Testing jams & team collaboration

We focused mainly on enhancements and iterations in the flow in the first week of three weeks mission. The engineering team was on fire and started implementing the hackathon code-base quickly, and we had a high-level working flow in the week-2 of the mission.

We have the ritual of testing each and every feature of the flow every Monday with the mission team and jot down the outcomes, as you can see on the document in the image. It helped us to eliminate all the errors before sending the flows for extended QA analysis to the team.

Tracking & UX improvements

We decided to track the whole feature flow by applying amplitude events on the main actions and tracking the adoption rate of the feature. Iā€™m responsible for analyzing the experience from the UX standpoint and making a backlog of hypotheses to improve the ease of use in the future. So far I have realized that the component of user selection can be improved and are already planning of experimenting with AB testing.