Challenges of online money transfer startups

online money transferThe existing money transfer players – Western Union, Moneygram, banks – have no incentive to innovate because online money transfer model will significantly change their existing mostly cash based walk-in business model. It’s very unlikely that any innovation will come from them. For example, it will significantly disrupt an agent network for Western Union. Even if they have technologies, resources and ideas the existing money transfer giants hold it back. It strongly reminds of Kodak – the company, which invented digital camera but hold it back being afraid that digital technology will affect its film based business.

There are probably more than 50 startups on the red-hot market of online remittance working on worldwide scale and even more than that on the local. Most of them are unknown startups you’ve never heard of and never will. Some of the most known names are Transferwise, Azimo, WorldRemit, Zoom (PayPal division).

The major challenge for online money transfer startups lays in establishing trust and brand recognition. In the crowded market, marketing becomes very expensive and hard to do. Almost none of the online money transfer startups have ever been in black. Even the most prominent ones such as Transferwise and Azimo are reporting losses years in a row explaining it with the need to expand and grow. Even the relatively mature Xoom under PayPal umbrella continues to report losses.

Another major challenge for remittance startups is technology and infrastructure. It’s impossible to be in a money transfer business today and not rely on the infrastructure owned by banks. The large portion of the money providers also relies on well-known APIs providers such as CurrencyCloud and TransferTo. You really can’t make it cheaper or faster or give customers better rates if you rely on 3rd party provider infrastructure. The key benefits the customers want are almost impossible to improve on unless you’re doing direct partnerships and agreement and building your own infrastructure that means huge upfront costs.

Some companies are hiding their fees by inflating the exchange rate against what is called mid-market rate or fair rate. It’s entirely possible to give customers rate even below the mid-market rate if you can create direct partnerships with the banks and other currency sellers and buy the currency in large quantities.

Customers want better exchange rates, lower fees, faster service. They are reluctant to try the new service unless they heard about it from multiple sources family and friends, online, TV and newspapers. Which is understandable because trust plays the deciding role in the customers’ decisions to try or skip the service. This means huge marketing expenses for the money transfer companies and insane cost per acquisition (CPA) that doesn’t correlate well with customer lifetime value (LTV). Most companies are making money on fees per transaction but the problem is most customers don’t send money on a regular basis it’s not like SAAS app where users are predictably paying monthly subscription fee – maybe bimonthly maybe once every few months.

It’s tough to create an ideal UX for the customers as money transfer process involves filling out a lot of forms and information. The underlying money transfer technologies often don’t provide reliable way to track status of the transaction, which usually leads to lots of customer’s complaints about the delays. There are also regulatory compliance where the company should obtain a remittance license in every country it operates and implement a set of anti-money laundering and anti-fraud requirements such as Know Your Customer and Anti-Money Laundering.

Money transfer startups require a lot of funding to support its marketing and brand recognition efforts; to be become really successful they need to invest in their own technology and infrastructure. From the business point of view, the small players are not going to survive in a highly competitive/high expense market where market share directly relates to revenue and profits.

How to do estimates in product management

product management estimatesHow would you estimate how long will it take to have build something, an app or a website? It’s easy to do the estimates based on historical data – if you’ve done already something similar before a few times. However, if you are building something not done previously it’s relatively hard to do the estimates.

Software estimation is very hard because often developers work on unique features and functionality. Then there’s collaboration within the team and often code changes in one area influence other areas as well.

Velocity is used to do pretty accurate estimates. Before starting the sprint, you do the sprint-planning meeting. Let say you have 7 user stories in the sprint. You’re not asking the engineers how long each one will take. You ask the engineers how hard is each story in terms of story points. There are different scales for this but as an example – 1 is the easiest, 2 medium and 3 the hardest.

After each story has a number assigned to it by the dev team, all the points are added and now your sprint has the total story points per sprint. At the end of the sprint, you see how many story points developers were actually able to complete. Velocity equals the sum of story points of each story finished per sprint. Usually each sprint equals to 2 weeks period. So for example if the team were able to complete 2 hard 3point stories, 3 medium 2 point stories and 2 easy 1 point ones, the velocity will be 14 points.

To predict the team performance more accurately and do the estimates better you use average sprint velocity that is average of 3 or more last sprints. So now, you see how much work can be done over a particular period of time (2weeks) in terms of story points. Now if you have an story points estimate from the dev team and you have past average velocity you can pretty accurately predict what time will take to ship specific feature or functionality.

Product Management Roadmaps

product roadmapRoadmap provides an overview how the product develops over time and adds new features and functionality. To build a roadmap Product Manager considers business requirements, market trends and engineering constraints. Once the roadmap created, it should be shared with the team so everyone is on the same page, ideally online so if there’s any changes the team will get the updates.

Roadmaps in agile environment are very inaccurate because you can’t predict 3-5 months in advance what’s going to happen. You’re prioritizing the most important issues to work on next but it’s difficult to say how much time will it take. On the other hand, maybe something else (feature or bug) will take over and this won’t be a priority any longer.

It’s ok to have quarterly product roadmaps as a general guide. The roadmap might be accurate as a general guide but it won’t be accurate to the day it says on the roadmap. Moreover, if it’s accurate then you’re not being agile.

So, why then most product roadmaps are aligned along the quarters? Executives and investors like the quarter based roadmaps. The stuff in the 3rd quarter won’t be accurate at all because we’re agile. Sometimes you can have actual hard deadline especially in enterprise B2B environment for large companies. They have commitment from clients and investors to ship certain features or functionality by certain point. Sales can rely on releasing of the specific feature that is not being built yet too.

What could be an alternative to product management roadmaps? More appropriate or agile way is just sorting things out by priorities or three bucket model: immediate bucket – here’s what we’re doing now, midterm – what we’re doing next, and another column – long term – what’s planned for the future. This feature prioritization intentionally leaves the dates out of the picture. Large companies such as Facebook and Google commonly use it in B2C segment. They don’t have to release certain product by certain dates. It keeps things inline by not expecting releases by a certain date.

How to communicate with developers as a Product Manager

developers communicationThe engineers love to have lots of details. So it’s a good idea to be very detailed when talking to engineers or emailing them. The engineers are always thinking about software and how what you’re saying may or may not work. What happens if the app doesn’t have connection to the internet? What would be the error state if something goes wrong on this page? What happens when no data is available to display on this page aka empty state?

The clearer your communication is the better. You’re bound for failure If you’re not detailed or clear enough in communicating with the engineers and sending them feature specifications. They love to get the details to know they are working on the right product. Which features are hard and which are impossible? Set the right expectations and be prepared to answer these questions.

Be a good listener and have empathy to listen to their feedback
Don’t rush the developers without fully understanding the technical challenges and long term impact. Don’t come up with all the concepts yourself or with the designer and then just hand the completed requirements to the engineers to code. Always provide engineers with the opportunity to give you feedback. If they spend the whole day coding doesn’t mean that they don’t have any good ideas or opinions. Actively involve them in day to day discussions. Product perspective not even the engineering one. Is this a good idea? Would users use it? During planning meetings tell what’s coming up next and give them opportunity to tell what they think about it.

Communicate clearly the vision of what expected of them.
Throwing away any work done by developers is extremely painful. Present your ideas with confidence. Make sure your stuff looks beautiful the developers should be proud of what they are making. If something goes wrong on the communication with the dev team it’s your fault. If they developed something incorrectly it’s because you provided the wrong specs.

Be wary of technical debt and be prepared to describe future of the feature
How the feature would look like in its ideal state and how it looks as MVP are two big differences. It will help them to plan out how it’s going to be done technically in the future. It’s something that needs to be reworked or refactored later as a result of not doing it properly/hacking the first time. Impending work. Engineers hate it because they have to deal with it. It’s a good idea to trust the engineers option on how to do the right thing first. Develop something scaled out to not do it later.

How to prioritize features

prioritizing featuresPrioritizing features, user stories and epics is one of the main day to day duties of anybody doing product management. It’s important to have set up a proper way of prioritization so that’s your team is building the most valuable features for the users and the most beneficial features for the company. Here are a few methods of prioritizing features.

Assumption Testing
This is a quick and efficient way of prioritizing the highest/lowest risk items. The goal is to derisk what you’re doing by removing the riskiest assumptions through analyze, user testing, data. You start with what remains to be unknown by finding out what the biggest and the riskiest assumption is. You assign to every feature value on a scale 1-10 and Importance score 1-10. The sum of these two scores allows you to do the ranking and prioritization. The main idea is to try and derisk by implementation what can’t be derisked further by other means.

The BUC method
This prioritization method includes evaluating of the business benefits, the user benefits and the cost as the criteria to rank and prioritize features, user stories, epics, marketing activates. You assign value 1-10 to each metric and then you subtract the cost from the benefits (user+business combined). Afterwards you can prioritize the items based on the final score you got. The highest ranked items will go to the top. It’s pretty challenging to do accurate estimate here because often there’s not enough data available. However, this is a balanced method which takes both costs and ROI of the items into consideration.

The MOSCOW method
The MOSCOW acronym spells for Must, Could, Should and Would. You take all your items and consider worst case scenario for each one – what would happen if you won’t implement this or build that? When things would go really bad? Then you would have a list of things which absolutely should be done. And you call this Must have’s. And you go over the rest and sort them through as the things that you could, should, or would do. In the simplified version, this can include two characteristics – must have’s and nice to have’s.

To sum it up, it’s up to you as the product manager and the company which method of prioritizing to choose and to use. Sometimes the best way is to go forward in planning what to build next is just using data and your intuition. Taking the calculated risks can get you the great benefits.


Rottweiler is the most stereotyped and misrepresented dog breed. I have a very nice and friendly one called Lima or officially Lima Von Vasfor because she’s a purebred. She’s part-time fitness instructor, part-time therapy dog and part-time house guardian.

Rottweiler Lima portrait

This infographic below, designed by my dear wife, is dedicated to Lima. This well designed and sleek infographic focuses on the Rottweiler breed, as well as facts and trivia. Continue reading

Go to Space Now!

Go to space now!

New revolutionary technology
We have to admit there hasn’t being any substantial space technology progress for the last 50 years, but rather only some incremental improvements. What we really need is a ground-breaking tech which will substantially change the status quo. Continue reading