Feb 17, 2025
A share button that changed the brief for phase 2
5 MINUTES READ
Most teams phase their rollouts like this: design the full vision, then cut scope until it fits the sprint. The first release goes out as a stripped-down version of the thing you actually want to build. The second follows when capacity allows. The third, if it happens, tends to be a negotiation between what was originally planned and what the business has decided it wants instead.
That's not a phased strategy. That's scope reduction with better branding.
The difference matters because a phase that exists only to reduce scope gives users a fragment — something that doesn't quite do what they need, justified internally as "we'll add the rest later." Users don't know there's a later. They just experience the now.
The actual problem we were trying to solve
At PropertyGuru, property search is rarely a solo decision. Couples, families, housemates — the people who end up buying or renting are almost always deciding together. But the product experience was built for individuals. You searched alone, you shortlisted alone, and then you screenshotted things into WhatsApp and argued about it with your partner over dinner.
The problem we were solving was real: users needed a way to track and share properties without leaving the platform. The long-term vision was collaborative — a shared workspace where two people could search together, comment, compare, and make joint decisions.
The question was how to get there.
The wrong answer was to design the collaborative workspace and cut features until it shipped. We'd have ended up with something half-formed — missing the social logic that makes collaboration work, because we hadn't built it yet.
Instead, we phased around a hypothesis.
Ship to learn, not just to launch
Phase one was a share button. A way to send a link to a saved property to someone else. That's it.
It sounds minimal because it was. But minimal was deliberate. Before building out collaborative features — shared collections, joint search, commenting, permission models — we needed to answer a prior question: do users actually want to share properties through the platform, or do they prefer the WhatsApp workflow they already have?
The share button was a measurement instrument. Not a placeholder. Not phase one of a feature-by-numbers plan. A way to observe real behaviour before committing to a more complex build.
This is the shift in thinking that most teams miss. Phase one has two jobs: deliver coherent value to the user, and generate a specific signal you need before phase two can be properly defined. If your phase one isn't designed to answer a question, you're flying into phase two without data. You're still guessing.
What the data showed
The share feature launched without a campaign. It was there. Users found it.
Raw click-through was modest, which was expected — property browsing is high-volume and often low-intent. People scroll listings. Most of them aren't actively shortlisting.
But the users who did share were different. They had more sessions. They submitted more enquiries. They were significantly more likely to return within seven days. Sharing correlated with active decision-making, not casual browsing.
Sharing was an intent signal. We hadn't designed it that way deliberately — we'd designed a sharing mechanism. But that's what the data showed.
That changed how we framed the next phase entirely. "Build collaboration tools" had been the brief going in. After the share data, the brief became something sharper: support joint decision-making between two people at the active shortlisting stage. That's a different product problem. It has a different scope, different interaction logic, different success metrics.
The data didn't validate the feature. It rewrote the brief.
Show the full vision even when you're only building phase one
There's a stakeholder management problem baked into phased delivery that most teams underestimate. If you ship phase one and it looks small, people will read it as failure or under-ambition — unless they already understand where it fits in the larger arc.
The tool I use for this is a storyboard: a visual narrative of the full experience as it's intended to work when complete. Not a roadmap slide with swimlanes. A story — here's the person, here's the problem, here's how the experience evolves across phases to solve it.
The storyboard does two things. It aligns stakeholders on the vision so phase one reads as the first chapter, not the whole book. And it forces the design team to pressure-test whether the phases actually hold together — whether each phase is genuinely additive, or whether you've just spread one design decision across three sprints.
At PropertyGuru, having a clear vision for where collaborative features were headed meant that a simple share button didn't read as a half-measure. It read as a deliberate first move.
What this actually requires from design
Hypothesis-driven phasing puts more burden on design upfront, not less. You need a clear question before you build. You need instrumentation designed around that question — the right events tracked, the right cohorts segmented, the right baseline established. And you need the discipline to wait for signal before committing to what comes next, even when there's pressure to just get on with it.
That's the part most teams skip. They ship phase one, declare it done, and move immediately to phase two without examining what they learned. The data existed. Nobody looked at it.
Phase one of Collections gave us a sharper brief for phase two precisely because we treated it as an inquiry, not just a delivery. The question was asked. The answer came back. The next build changed as a result.
Design the phase. Define the question. Let the answer earn the next build.