Behind every product and feature is a story. It’s a story of how business goals and market needs are shaped into concrete product requirements, designs, and experiences that ideally bring returns to the business and value to users. In this article we look at some of these stories, and figure out what it takes to ensure that these stories of translating business into product have a happy ending, and are not lost in translation.
We talked to two product leaders — Damien Passavent, Head of Product at Aspire, a neobank platform for SMEs in Southeast Asia, and Jefriyanto Jefriyanto, co-founder and Chief Product Officer at Payfazz, an agent-driven, mobile-first fintech platform for Indonesia’s underserved rural economy.
Both Aspire and Payfazz have recently been hitting milestones, with Aspire launching a platform upgrade — Aspire 2.0 — and partnering with TransferWise for forex services and Payfazz closing a US$53 billion Series B round led by B Capital and Insignia Ventures.
We asked Damien and Jefri to share their approach to translating business into product through the lens of two case studies of products or features they have developed. We explore 3Ps key to this endeavour: process, people (users), and product managers. Below we identified key takeaways from each case study and “P.”
Case 1: Process — Aspire 2.0
Recently Aspire launched Aspire 2.0 featuring a new user experience. We talked to Damien about the behind-the-scenes of Aspire 2.0 and the learnings from the process thus far. Damien outlined what it took to build Aspire 2.0 in a five-step process.
Step 1: Identifying goals.
For Aspire, what they wanted to achieve with Aspire 2.0 business-wise is to increase conversion rate from leads and signups to their north star metric: engaged accounts (repeating, loyal customers). As much as possible the product team didn’t want to create new features or services to achieve this, but simply elevate the overall user experience on the app. But there are so many ways the app can be improved. How did they zero-in on specific changes on the design level?
Step 2: Structuring the research.
According to Damien, it was important that they structured their research. That way they could extract meaningful insights from the data and feedback they were getting. They started with at least three high-level questions to guide their research:
- Is there something to be improved on the level of our existing features?
- Do users understand what they can do with the product? (product discoverability / user guidance)
- Do users feel secure using the product? (trust)
PMs and designers listed more questions to serve as guides, but they focused on product discoverability and trust in particular as a fintech engaging in business banking services. Users need to be able to adapt quickly to the digital experience, especially coming from offline processes, and also trust that the product is secure and able to deliver on its promises.
Step 3: Casting a wide net on data.
Then over the next two weeks, they fired up all their engines to answer these questions, looking from all possible directions, from customer interviews to market research. They cast the net wide on existing and new data sources, from looking at past NPS surveys to using tracking tools like MixPanel or FullStory to see where customers are struggling, dropping off or converting. Regardless of the size of the net cast, however, the data should ultimately come from the customer. As Damien put it, “The high-level objective is to be able to see our product through the eyes of our users.” Without casting their net wide, they wouldn’t have been able to generate a pool of insights from which to meaningfully filter for actionable items.
Step 4: Extracting signal from noise.
After amassing information and insights, they identified multiple areas of improvement on the app, from the log-in experience to FAQs and product support. Then they began to sift through the areas of improvement they could act upon on a design level. The high-level questions around transparency and trust narrowed down the areas of improvement to focus on.
Eventually, they landed on some key changes that Damien summarized as “making the app more human-friendly.”
“Through the product, we are talking to the customers, and we wanted to make sure that using Aspire would be as easy as talking to a human assistant.”
Step 5: Designing solutions.
These changes include adding a Discovery section in the home tab, dedicated pages to explain Aspire’s regulatory setup, making FAQs and customer support accessible from the home tab instead of settings, and rewards for going through a step-by-step onboarding guide. Interestingly, the most significant changes were with the copywriting in the app than any of the features.
The design changes Aspire’s team have made thus far were not complex technologically but were focused on what they wanted to achieve: an improved user experience centered on product discoverability and trust.
To design these changes they cast their net wide as well, not only looking at best-in-class neobank apps but also apps in other verticals to learn how they did their rewards programs and gamified onboarding. Then the team went through several days of design testing, both internally and with customers. Aspire’s product team put their solutions through rigorous experimentation before implementing any of the design changes.
And the result?
Since launching Aspire 2.0, the product team has been monitoring response to the changes. According to Damien, it’s still early to quantitatively determine whether or not the changes will result in increasing conversion rate to engaged accounts, but so far they have been receiving good signals from NPS score. Damien mentions several customers reached out to them to share that they find the new design much more intuitive. Aspire’s product team also observed from FullStory that customers don’t hesitate as much as before, and do what they need to on the app faster than before.
Given the changes to the app, tracking tools have also had to be revamped. For Damien, the challenge for his team is finding out what percentage of the impact can be attributed to the specific design changes and what percentage was influenced by other factors like new features developed in parallel and communities initiatives by the marketing and growth teams.
Though the changes to the app aren’t complex per se, what adds a dimension of complexity is rolling out these features in different markets. For example, rewards for going through onboarding steps had to be different for Indonesia and Singapore. In Singapore, they already had a business card available, so they offered cashbacks on card payments, while in Indonesia they presented a rewards scheme based on the frequency of money transfers.
From the engineering perspective, the product needed to be developed in a modular manner, given the number of steps and outcomes could vary from market to market. It also requires a robust technology architecture to house these use cases.
Aspire 2.0 process of translating business goals to product
- Identifying what the business wants to achieve.
- Structuring the research.
- Casting a wide net on data sources for insights.
- Extracting signal from noise.
- Designing solutions.
Case 2: People — Agen Terdekat
Payfazz developed Agen Terdekat (literally translates to Nearest Agent) around a year ago to address the simple pain-point that their agent-driven network needed closer top-up points than banks. In Indonesia’s rural economy, traditional banking density is low, and while Payfazz had set up an offline banking network through warungs and small restaurants, they needed to be able to keep transactions flowing without having to rely on the presence of banks. It also allows agents to act as customers for other agents as well.
From a growth perspective, implementing this feature offered greater visibility for the Payfazz brand that would be more cost-efficient than topline marketing efforts like billboards. The feature would leverage on Payfazz’s already existing apps and network of agents to grow market share, instead of having to create an entirely separate marketing campaign or initiative.
To develop the app, they ran cross-functional pilots with their operations and customer service teams and only tapped into engineering when the initial experiments worked.
According to Jefri, they measured the effectiveness of Agen Terdekat with the “virality of the user.” When a Payfazz agent gives advice or recommendations to another user through the feature, they leave a referral code on the platform. Combining the referral code with social interaction lets Payfazz’s product team translate offline social interactions into online tracking.
Tapping into social interactions through a feature like Agen Terdekat worked well for Payfazz because of the strong interrelational aspect of communities in the rural economy. Pain points are tied to deeply to very human and basic needs, and businesses live and die by the trust they build with the communities.
As Jefri put it, “Building for the rural economy is tricky because you are dealing with strong trust issues and emotional issues. You have to pay more attention to the emotional needs and interactions of users when implementing solutions for them.”
Developing features like Agen Terdekat, from observing user interactions to creating features or products based on what they learn, is rooted in Payfazz’s desire to better the lives of their users. While layered on tight-knit relationships, it can be concretized simply as an increase in personal or business income.
“The goal is not to create features as many as possible, but try to give several solutions for our users and agents for increasing their income,” says Jefri.
The first case on Aspire 2.0 highlighted how having a structured process to bag up a lot of insights and then spot the key pain points they could address helped better translate their goal of achieving better trust and transparency (and thus more engaged accounts) into concrete design upgrades. Even though Damien says that Aspire 2.0 is still a work in progress, it’s important to have structured routines as SOP.
The second case on Payfazz’s Agen Terdekat feature described how paying close attention to the relationships and interactions on-the-ground allowed the product team to design a feature that would help create more visibility for their brand, increase activity on the app, and more importantly, strengthen their distribution network.
Then there’s a third P, common to both cases: product managers. Damien says, “Translating business goals into product features is literally the job description of a product manager, so I’d say it’s important to have solid product managers who listen a lot to customers and are analytical enough to translate vague inputs into concrete requirements.”
But more than hiring solid product managers, Damien points out that culture management is important too. It’s important to emphasize the value of listening to customers. “It’s important to let PMs know that what we are doing, in the end, is empowering our customer to get something done efficiently at the lowest possible cost.”
For Payfazz, this is reflected in their pro-customer culture, which is not just about listening to what people say but also closely observing what people do.
“It’s not about building as much as possible but building as much as the users need…Sometimes they also don’t know what they need so we make sure to always talk to them and get more insight from what they do,” says Jefriyanto.
These 3P’s all contribute to exercising the organization’s empathic muscle as it lifts the demands of users and the market and carries it over to the product or service of the company. And as with any muscle, it must be used often to be ready for any challenge.