In this piece
Pivot the MVP or change the user flow? The Offlinery decision
A match appeared on the phone. Our client expected the next move to be a hello in person. Some Offlinery users sent a message instead, arranged a spontaneous date and then met. For the team deciding what to build next, the most revealing part was what happened after the message. The people who put down the phone and went for coffee still wanted the encounter the product had promised.
Wavect helped the client design and build Offlinery. Faced with mixed feedback, we had to decide together how much of the product to change. The person being approached ended up with a choice. They could leave messages off until after meeting, or allow one or two before someone walked over. The public repository documents the original purpose. Offlinery shipped on iOS and Android and wound down in 2025.
What did a match within 25 metres tell you?
Offlinery could tell you that someone nearby was open to being approached. Before development, we and the client had drawn on interviews and secondary research. Our starting hypothesis was that women who wanted men to approach them in public would welcome a way to signal that interest. People could choose to approach, be approached, or do both. They could also set times when an approach suited them, as the original onboarding options show.
As I remember it, a nearby notification went out only within 25 metres. At that distance, you might already see one another. The phone added something you couldn’t see. It told you that the other person had opted in. What it couldn’t tell you was whether they wanted you to walk over right now. A quick exchange gave the two people a way to settle that between themselves.
Who got to choose whether to hear from someone first?
The person being approached could decide whether to receive a message before meeting. This mattered in both directions. It gave someone who preferred a heads-up a chance to respond, and it let someone who wanted a spontaneous hello leave the phone in their pocket.
| Preference | Before the first hello | After meeting |
|---|---|---|
| Come and say hello | Messages could be switched off. The other person could introduce themselves in person. | The two people could write to each other. |
| Write to me first | There was room for one or two messages before walking over. | They could follow up after their conversation in person. |
The encounter screen’s own guide gives a good example of a follow-up. If you forgot to give someone your number, you could leave them a message. The two modes above come from my account of the product decision. “One or two” describes how brief we wanted the exchange to be.
What were people trying to do when they wrote first?
Some wanted to check whether the other person would welcome an introduction at that moment. Consider an opener like Would now be a good time to come say hi? A reply can settle the question in seconds. If we had looked only at the number of messages, it would have been easy to miss what happened next. People put their phones away and met.
Others told us that letting a stranger know they were close by felt uncomfortable. Everyone who wanted to approach someone had a personal verification call with the project team. We also used reviews and reputation, adjusted the matching algorithm and could ban accounts. The app’s introduction to screening shows what people saw. Someone could understand all those precautions and still prefer a message before a stranger walked up.
When a team brings us a similar feature request, I want to hear about the last time it happened. What did the person do immediately before opening the app? What did the reply let them do next? That second question would lead to different designs for someone hoping to talk all evening and someone hoping to put the phone away.
We explore a related scoping mistake in our article on teams that keep shipping features. For a team planning its first release, this is a useful question for software product discovery.
When does unexpected use justify a product pivot?
Before you fund a change, reconstruct the last time someone took the unexpected route. Ask what they were trying to achieve, what they did next and how they knew they were finished. At Offlinery, an interview answer about wanting an in-person introduction could tell us little about whether someone wanted a stranger to walk up unannounced. The sequence of actions exposed that second assumption.
| What you observe | What to do with the next development budget |
|---|---|
| People take an extra step, then reach the intended outcome. | Test a smaller change to the flow. At Offlinery the recipient could allow a brief exchange before meeting. |
| People consistently stop after the extra step because it delivers a different outcome they value. | Investigate that outcome with returning users. Check demand and willingness to pay before funding a pivot. |
| Your dashboard only records the extra step. | Budget for follow-up interviews before expanding the feature. The event count alone fits either explanation. |
The same question applies to a B2B purchasing portal. If a buyer emails an approver and then places the order in the portal, ask what confirmation the email supplied. If the buyer routinely finishes the whole purchase by email, find out why the portal drops out of the process. Those observations justify investigating different changes.
How would we test whether the first message helped?
If I were testing this decision again, I would ask both people, separately and voluntarily, whether they spoke in person and whether the approach felt welcome. I would use the nearby match as the starting point. Counting only people who exchanged messages would leave out everyone who chose the direct approach.
I would keep unanswered follow-ups separate from people who explicitly said they never met. I would also keep the two preferences separate. Someone who chooses a heads-up may already feel differently about being approached, so a difference between the groups alone wouldn’t tell us what the feature caused. We have no before-and-after figure to publish for Offlinery. Those are questions I would test today.
The technical Offlinery case study explains how we got a nearby match onto a locked phone while there was still time to meet.
When a product committee has a pivot on its agenda, bring a recent account of how someone used the product to a software discovery session. If the disputed step is already clear, tell us what the customer did next.