A product becomes meaningful when it fits into the rhythm of someone’s life. A business has a set of services, a set of technical capabilities, and a set of constraints. So, often a product gets framed as: how do we package this service into an interface? How do we let someone do the thing, quickly and safely, with the least friction? It’s an important foundation to have, but is rarely what makes products meaningful.
In reality, what makes a product stick is what sits around the core function: peripheral expectations that appear once the market reality changes. You will find that users come back to a product because the experience around it makes them feel like it understands their life. When you are able to build around these opportunities, you have a useful product.
Services are the starting point, opportunities are the product
Let’s take something everyone understands: transferring funds.
What you will read next is an intentionally simple example to make the core idea easier to see. In reality, banking systems are far more layered.
From a business and infrastructure standpoint, “fund transfer” is already a heavy lift. You need the plumbing to move money between accounts, reconcile balances, and coordinate with other banks. You need authorisation flows, you need to keep the regulator in the loop, and you need messaging systems that can send SMS or email confirmations, among other things. That’s the service.
Now the product question usually becomes: what is the cleanest interface to let someone transfer money? Let them enter an amount → show balance → confirm → authenticate with an MPIN or OTP → done.
This is where many teams might stop. They might assume that the best experience is simply the easiest way to consume the service. But users don’t experience fund transfer as “fund transfer.” They experience it as: who am I sending money to, how often, and what do I need around this activity so that it fits into my life without stress? So the opportunity is rarely the transaction itself. The opportunity is the world around the transaction.
Expectations evolve with every update
When a technical problem is solved and turned into a product, it changes what people consider normal. For instance, once people have an app, and don’t have to physically go to a bank to transfer money, they get used to the new baseline. Once they’re used to that as well, they stop evaluating the app for simply enabling transfer. They start expecting it to help them transfer in a way that matches their habits.
So the opportunities appear immediately.
If adding a payee takes three hours, that is also a part of the fund transfer experience, even though it’s not the “transfer” step.
If I send money to the same person every month, I want to see them right away, and I want the experience of the app remembering the last amount I sent.
Google Pay shows recurring payees with their last payment amount, letting users repeat monthly transfers with a single tap.
If I’m typing in a large number, I want reassurance in the form of the amount written out in words.
If a transfer succeeds, the success screen is not just for my confirmation. It is proof that I may need to share with the person who received the money.
When users make a payment via CRED, they can share the receipt to the payee for confirmation.
These are not one-off examples or edge cases; they’re a part of real life habits and needs pressing against the core service. And that is the point: the reality of people’s activities does not map neatly to how technical requirements are written. It is the product, and consequently the product makers, who have to do the translation.
The medium changes the expectations
This is not unique to banking. Let’s take a few examples:
When e-commerce arrived, the change was simple: you didn’t need to go to a physical store, you could just shop online. For instance, you didn't have to go to a bookstore to buy a book. You could just order it online, and it would get delivered. That becomes the new normal.
When watching movies or shows, you would either discover them on television and watch what was playing or purchase or rent DVDs. But with streaming, you can watch what you want, when you want.
Similarly, earlier you needed to call and book a taxi in advance before a trip, or step out and hail one. But with today’s ride-hailing apps, you can just summon one to your exact location.
Before food delivery apps, the norm was to have a bunch of menus in your house, and call your favourite local restaurant for delivery or dine in. Now, you can browse, compare, see pictures of the food along with descriptions and, in some cases, calorie information, and order in minutes.
What happens with all of these changes in medium is that new expectations start to emerge. Suddenly, you want to be able to save items for later. You want to see what others are saying about a book before buying it or about a movie before watching it, as you’re browsing through them. You want recommendations based on what you’ve liked or seen. You want different browsing experiences. None of this was expected in a physical bookstore or DVD shop. You would not stand there asking for reviews to be displayed under the shelf. Similarly, with ride-hailing apps, you can see your driver’s profile, how many trips he’s made, what others have said about him, and how long he’s been driving.
But the medium changes the expectations, and that’s where opportunities exist. The same thing happens with food ordering. The moment discovery becomes possible, behaviour changes. The product expands from “place an order” into taste, exploration, memory, and convenience.
This is why opportunity thinking matters. It helps you see the expectations that form around a transaction, and then build those expectations into the experience.
Opportunities are the adjacent reasons why people come back
A product can’t rely on users repeatedly returning just because the core function exists. Once a function becomes normal in the market, it stops being the reason someone chooses your product. Opportunities are the adjacent reasons that make the product compelling enough to reuse, and constitute the ‘experience’ of the product. These are the differentiators that evolve after the base capability has been invented.
Whenever a user is on a call and tries making a transaction via the ICICI iMobile app, it shows a pop-up to alert them against cyber crimes. It's a protective element that builds trust and keeps users coming back to the secure app.
That is why “opportunity” is not a buzzword for us at Canvs. We very much consider it a practical design lens. If you identify the peripheral expectations around a core transaction, you can give users something that fits how they actually operate, and that gives them a reason to return.
So, how do you identify these opportunities?
There is no set process to this; instead, it’s a model of thinking, and it’s important to be honest about that. One part of opportunity-spotting comes from experience. Senior designers are not valuable because they have spent more years doing design. They are valuable because they have developed a way to model people’s expectations around a task. They can enter a new domain and still ask the right questions, because they understand how humans work with software.
Even when the industry is unfamiliar, a senior designer benefits from their years of crafting experiences. Over time, they've built an internal model of how people behave around everyday activities. They know how to recognise patterns where anxiety appears, where reassurance matters, what people repeat, what they resist, and what they assume will happen next.
Predicting human behaviour around core tasks becomes a muscle senior designers develop through years of exposure. The other part is research.
In mature industries, looking at how other products have evolved is a fast path to understanding the landscape. In newer industries, you rely more on observing behaviour and noticing what people are doing outside the product, and what could be brought into it.
You can also draw parallels laterally. You can look at how people behave in adjacent contexts and make grounded guesses about what they might expect here. Opportunity spotting is not magic. It is common sense, but quantified and made explicit.
Designed into the system, not layered on top as extras
This is where teams usually misstep. They treat opportunities as features or something to “add” on top of the product. But real opportunities are rarely surface-level. They tend to demand changes at a structural level.
If users would like to have favourites and be able to do quick repeat transfers, the data model has to recognise those patterns of usage.
On the ICICI iMobile app, the user can see their "Favourites" payees to whom regular payments are done. It also shows "Recents" payees to repeat the same payment quickly.
If recurring payments matter to people, the system has to be able to accommodate standing instructions within banking and regulatory constraints.
Revolut's recurring payment flow lets users set up standing instructions with flexible scheduling. It's an adjacent capability that makes the core payment function more powerful and reduces friction for predictable expenses. (Source)
If budgeting is the goal, transactions can’t just be logged; they need to be meaningfully categorised.
But an opportunity is not a feature request. Sometimes, it arises within a system that can already support it, and the job then is to design it carefully into what exists. At other times, it can expose a regulatory or technical constraint, and the job then is to adapt to that reality. It’s rarely as simple as spotting a gap and shipping a feature.
The better question is: Where does this opportunity actually live? Inside the current architecture? Adjacent to it? Or does it expose something the system itself needs to reconsider? That judgment call is what keeps products cohesive.
A simple example: How budgeting and transaction notes become opportunities around payments
A payment product can do payments and stop there. That is still a product. But one of the most natural user thoughts around payments is: how much am I spending, and where is it going? That is budgeting. And it becomes an opportunity for the service of payment.
If the product gives a user a way to understand their spending behaviour, that user has a reason to return and check patterns, even when they are not actively making a payment. And importantly, when they do transact, the product now captures more data that improves the budgeting layer.
Sometimes, the opportunity is even simpler. Consider transaction notes. A small prompt for “Add a comment” takes seconds. But over time, it turns a bank statement into moments—’Dinner with Rohan’, ‘Freelancer advance’, ‘Refund for shoes’— and the context for why certain payments were made.
On Google Pay, the user can add a simple transaction note to their payment for reference.
Very little effort per transaction. Very high upside in usefulness. The service powers the opportunity. The opportunity makes the service stickier. That relationship is what you’re looking to build.
The benefit to businesses
When opportunities are baked into the experience, users have a stronger reason to stay, return, and rely on the product. This changes usage. It changes trust. It changes how central the product becomes in someone’s life. And when the product becomes central, the business has more room to grow. Not through vague “value,” but through a clearer exchange: people pay attention, time, and sometimes money when a product gives them conveniences they actually care about.
People don’t want tech, they want what it lets them do
A technical invention is rarely the product of itself. Let’s take file transfer, for instance. It existed decades ago, but nobody cared about it as a standalone capability. People wanted networks, access, and movement at scale. The value was in the experience that formed around the core tech.
That is how products evolve. A market gets created, the baseline becomes normal, and expectations grow. The winners are the ones who see those expectations early, model them clearly, and build around them with intent.
This is what an opportunities-based approach is doing. It starts with the function being offered, but it doesn’t end there. It asks what life looks like around that function, and then shapes the product accordingly. In the end, the product is not in service of the business alone; it is in service of the user’s experience of their very life.
