What we learned shipping the Plans feature to 40,000 groups

We shipped the Plans feature in November. By February it was being used by 40,000 groups. This is the first chance we have had to write up what we learned — partly because the rollout was bumpier than we expected, partly because we are still learning.

The original premise

A "plan" in MyPerfectStay started as a glorified shopping cart: a list of activities the group had voted on, in chronological order, with a sum at the bottom. Pleasant enough. Useful, sometimes. Not the thing we hoped it would be.

The problem became clear within the first month: groups were filling their plans with optimistic activities, then deleting most of them an hour before the trip started. The plan was acting like a wishlist, not a commitment device. Nobody trusted it.

Redesign one — adding stakes

We tried adding deposits. If the group wanted an activity in the plan, somebody had to put 10% down. This worked, financially — booking confirmation rates went up 18%. It worked, socially, badly: the friend with the credit card felt like they were running a bank, and the friend who never paid first felt judged.

We rolled it back after six weeks.

Redesign two — the time grid

We rebuilt the plan as a calendar grid: hours running down, days running across. Activities had to be placed on the grid, with a duration, with travel time. This was, in retrospect, the worst week of my year. The calendar grid demanded a level of planning precision that no group of friends had ever wanted to provide. Engagement on plans dropped 60% in two weeks.

The lesson: never make a tool more sophisticated than the user's actual mental model.

Redesign three — the soft vote

The version that finally worked was simpler than either of the first two. We added a single new state to each activity: interested. Not committed. Not in the plan. Just — interested.

Interested activities are visible to the group, but they don't count toward the plan unless three or more people mark them. Once they cross that threshold, they get added to the plan automatically — without anyone having to "decide."

This sounds trivial. It was the most important design change we have made.

The soft vote let groups express preference without taking responsibility for it. The implicit threshold (three) gave the group a clear, fair signal of consensus. And critically, no single person had to be the one who "added it." The plan filled itself.

The embarrassing bug

For three weeks in January, the soft vote threshold was hardcoded to 2 in production, not 3. We did not notice. Plans were filling up faster than expected, but we attributed this to the feature working. A user emailed us asking why their plan had a kayaking trip in it that only their cousin and their cousin's boyfriend had voted for. We checked the code. The cousin and the cousin's boyfriend, it turned out, were both correct.

We shipped a fix the same day. The kayaking trip went ahead anyway. The user later told us it was the best part of their holiday.

What's next

We are now working on the inverse primitive — a way for groups to un-soft-vote, gracefully, when interest drops. It turns out the harder design problem is not adding things to a plan. It is removing them without making someone feel bad.