Free Team Plan (Postman 6.2)
Postman in its earlier years was about building new functionalities according to market needs and making them robust. Once we achieved that to some degree, we wanted to work on our growth strategy. The following case study is about my involvement into one of our most successful growth experiments.
The conversion funnel in Postman looked like this:
Free user → Start trial → Purchase Pro plan → Purchase Enterprise plan
The trial plan offered all the features of the Pro plan and lasted 7 days. Trial plans had a steady conversion rate and we were looking to increase it. Our brilliant data science team reported that most trials were only used for a while immediately after starting it and a little in the end. Throughout most of the duration, the team would remain inactive. Moreover, after the trial got over, a lot of teams would ask us to extend their trials because they didn’t really explore Postman fully. The time frame was failing to create urgency and instead keep people from trying the product at their own pace.
We realised the trial plan was having a very limited impact in helping users decide if Postman could provide sufficient value to their teams. We needed another way to show this value without limiting it in a time frame.
After some deliberation between the design, business and marketing teams, we came to the conclusion — We should get rid of the trial and instead make collaborative features available to all users so that they can create their team at their own pace. This should allow a small group of people working on a single project to have a taste of what value Postman can bring to their workflow. When their needs would outgrow this, they would be fully prepared to jump completely on board.
I was to lead the design with inputs from business and marketing since this was going to have a major impact on both. Vineet (my fellow designer) was not actively involved in the project but helped me throughout the journey by always questioning my assumptions and helping me navigate through tough decisions.
In order to make this work, I had to overcome two challenges:
Challenge 1 — Improve flows for inviting and sharing- Postman had limited ways for users to invite their colleagues to Postman since it was only paid teams who did so. These teams would have someone who was in charge of setting up the team so it wasn’t a problem. But if we are to allow everyone to form teams and share things, this would have to be super simple.
Challenge 2 — What and how could we restrict without this affecting experience- While we did want people to start using Postman freely with their teams, we had to draw a boundary somewhere. Should we limit the number of people who could collaborate, or limit the number of things they could collaborate on? What could give the users the full flavour or Postman without being too restrictive? How do you give freedom to teams to try things out while preventing them from abusing it?
The first challenge was straightforward. We had to make the invite action available from a place where any user would expect it. This turned out to be the workspace as the purpose of a workspace was to allow people to collaborate on a shared context. We were already allowing people to invite team members to workspaces. We extended this so they could also invite people into their team.
The second challenge, imposing a limit, was tricky. Whenever the product does not let you do something, it leads to a bad experience. Of course we could mitigate this by letting users know well in advance that they would hit this limit. But would it be enough? We were trying to make a sticky product. That’s why we wanted to provide a way for users to continue working even on hitting a limit.
This is where we introduced the archiving feature. The idea was to let users continue working even after crossing the limit on shared resources. The limit would however prevent you from working together on older resources. In essence, this let us define the product such that a small team working on a couple of products would be able to freely use the product while also prevent abuse of the system by bigger teams working on much larger projects.
Testing it out
We started testing it out as soon as we had a crude build of the app. Vineet and Anudeep (fellow designers) helped conduct some of these sessions. Our testing group of 5 included working professionals with different profiles and experience levels. We focused on three areas, creating a free team, joining a team and understanding usage limits.
Based on learnings from the sessions, we fixed some minor bugs in the flow. Some of the participants interestingly tried to invite others to their team in the flow where one shares resources with his team. This was something we hadn’t anticipated and we introduced a way to let people do that.
We did a limited release when we which also got us some constructive feedback leading us to rework on some of our messaging and notifications. This feedback was different from the usability sessions because these users were operating outside any controlled environments. Based on their feedback, we also included a grace period of 15 days until the ‘archiving’ kicks in so that users had ample time to understand the process.
After full rollout, we saw people taking to this immediately. The number of free teams grew at a rate beyond our expectations.
Impact on conversions
The number of monthly conversions from the free plan to paid plan were >30% higher than what trial plan used to have. The number of direct purchases did not see such a drastic jump and we concluded that most of this increase was because of the the newly introduced plan and not because of other factors. Over time, the ratio of purchases coming from the free plan as opposed to direct purchases is increasing. This is a positive trend that we didn’t see with the trial plan.