“Know more than what’s within your scope” — how Anthony Oduu creates a growth-focused roadmap

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

Question all roadmap ideas

Anthony is a leader who clearly understands the devil is in the details.

For him, making one decision about the product’s roadmap creates a network of ideas to verify. He asks for mockup drawings to come with the specifications or considers how a new feature could influence a user to recommend Verto’s service.

And he knows how to visualize the customer’s business model to be sure that Verto’s solution is a matching fit rather than guesswork shielded with unverified data.

To understand what influences Verto’s roadmap decisions, we went through engineering and visited marketing, finance, and business development.But it all comes together in the end.

From this story, you’ll learn why Anthony:

• insists on calculating the value Verto’s clients get from any feature,
• pretends to be lazy to test UI changes,
  
• believes in pay-per-use software models.

Learn how these concepts influence how Verto’s IT works daily.

About Anthony & Verto

The art of respecting the user

Eric Ignasik: Hi, Anthony! I’m really excited to start this interview. May I ask how often you evaluate Verto’s competitors and what your process is?

Yeah, that’s a very good question. I monitor other fintechs nearly daily. I’m subscribed to a lot of news alerts to read their features in media or product launch notes.

My school of thought says: know what your competitors are doing, but not because of jealousy or the desire to imitate them. 

For me, it’s about understanding how different people — let’s say — adjust their products to the same regulatory framework.

I also need to understand their product completely. Do they have a feature that can add value to our customer base? Is it competing with what we already launched?

Obviously, other businesses will attempt to model their operations after Verto, so it is important to watch them. 

Otherwise, you won’t be able to build a compelling product or innovate.

Eric Ignasik: In our research, we noticed that Verto says it has 3,000 business clients, which suggests the platform is quite popular.  

What rules make your roadmap discovery different?

My vision for the roadmap often changes every year to align with Verto’s commercial strategy.

I categorized changes into several tiers for the last year and a half. Tier 0 is anything the audience needs to have built where we have no other option than to deliver.

The tier 1 category of the roadmap is for features that improve Verto’s efficiency, which is critical because we built our internal tools in-house.

External plug-and-play solutions didn’t fit our needs. We’d need a provider with the same roadmap and strategy to avoid the risk of migrating to a new technology if they change their software or operating model.

Now, I follow three rules when creating the roadmap. The first one — any new initiative must increase operational efficiency. 

The improvement could be from 1 to 5 or from 10 to 100 percent. What’s really important to me is the absolute value the customer receives.

My second rule is that the initiative must serve enterprise customers that we’d like to sign up more of.

The third rule is something I believe should be widely adopted. New development projects must clearly impact revenue, which is our North Star metric.

Now, a feature might not be commercial by design, but if it can shorten the time it takes to complete an outbound transfer from 10 minutes to 1, users will probably do it more often, so the improvement can be attributed to revenue generation.

So, those are Verto’s rules for creating the roadmap. Beyond that, we have been prioritizing removing technology debt, which we have around 6 months of.

And it’s not because Verto’s infrastructure is broken or no longer performing. I know that after one more year with that debt, something’s gonna break.

That sounds like a very reasonable approach. Serial entrepreneurs suggest that most startups fail because of a weak product-market fit or bad marketing.

Could you tell me what else your Business Analysis team does to ensure that a feature idea is right? 

Since we work on cross-border payments, I’d like to ask how the idea adds to a country’s GDP. 

Will it help a small business owner send a payment to the vendor in a day instead of three weeks? 

Because that could let SMBs save on cash flow, and in turn, owners wouldn’t have to worry about selling all their goods early into the month

They would also avoid having their stock sold out too early.

Every product we launched in the past three years has been in beta for like 6 months to get enough customer feedback.

We also ask if the product needs to be localized for new markets. Sometimes, releases fail because of the nuances of a market rather than the build.

They can be as simple as calling customer service and getting an immediate response. Understanding all of the users’ possible expectations before anything is built should guarantee success.

But we also examine if our brand is recognizable enough. 

Now, you can spend money on colorful billboards or Google ads to get people to remember your company, but that doesn’t mean they will get involved with the product. 

They will probably skip your ad if you disrupt their YouTube session.

That’s where growth marketing comes in. It creates multiple touchpoints for Verto that somehow get us involved with the local society without strictly selling to it. I tend to focus on the actual growth element of it.

For me, Marketing has to be systematic and create a unified experience. Hoping someone will love the brand just because it is splashed everywhere on billboards is pointless.

What is Verto’s process for ensuring your platform is the better choice for customers than competitors such as Corpay or OFX?

Note that Verto is different as it’s focused on emerging markets, like Africa, where some currencies are very, very illiquid. 

The continent has regions where you can’t just go to a bank or provider with a pre-made solution to plug into, display your customer’s data, and earn your margin.

In our case, we had to build a liquidity management solution behind the scenes. 

Imagine if you wanted to exchange a large volume of Euros for Kenyan Shillings as a B2B customer, which is who we work for.

It’s harder for them than for individuals to get access to real-time pricing and do an instant payout at the bank.

We made sure that our UI had enough clear information for our customers to know what they’re getting charged, what their 1 million euros gets them in their client wallet, and when the transfer will be delivered.

For liquid currencies, like G3 or G10, our service seems like anyone else. 

We give you a price, note if any fees come with it, and you get money straight away into your wallet after the exchange.

If you ask us to do payment for you as well, we’ll do that, too. We want you to be able to deliver your payment as quickly as possible to your suppliers or to do your payroll.

But we have additional services that make Verto different.

Our design includes safeguards for situations where a business wouldn’t get its transfer put through after exchanging currency because it is from a specific jurisdiction. 

We’ll prevent them from making the transfer in the first place so that they don’t have a poor experience.

Verto’s platform also lets two anonymous business users trade directly under their own rates but within our compliance rules. You can set your own currency price, and there might be demand for your supply.

Actually, hundreds of customers sign up just for the price discovery function.

And that’s everything we do differently from our competitors in the space. Of course, it works well because of the emerging markets we focus on.

Michael Sols: You suggested simplifying the user’s journey. Did you or Verto’s first hires study the experience of using other payment platforms?

Yes, I did that just today. I always describe myself as a lazy user. When I log into any app, I try to switch off my brain to forget what I’m doing there.

The UX should be prescriptive enough to lead the user on without them needing to understand everything. So, for me, a very good user journey is one where a customer can be lazy.

I’m not browsing other platforms to criticize but to borrow their experience. I love design, and even though I had to give it up in my role, I like to be included in the sign-off.

It doesn’t matter how good your technology stack is. The customer doesn’t care. They just want to press one button which will run a thousand operations for them without getting confused. Verto tries to follow that philosophy.

When the team was small, we all worked together. But even now, if someone comes to me and says: “Hey, Anthony, I’ve got an idea,” I want it visualized, although I might understand it.

If you don’t know how to design, I’ll just ask you to bring out your pen and paper.

When I used to work in banking, my previous boss told me that spoken communication provides only one interpretation that the speaker creates.

If what I say is misinterpreted, I didn’t communicate properly. I believe design works this way.

Usually, I answer new requests by asking: “Where does it fit into the existing solution? Does it change the UI?”. If the answer is yes, show me. 

So it doesn’t matter what you explain to me if the design makes no sense. Even our software engineers or tech leads — who might not like to design by default — map out the user experience for others.

Sometimes, I gave three or four people the same task to create mockups. Then, I got everyone on the same call, reviewed four or five different ideas, and we created the best version. We still do that today.

What makes Verto’s roadmap work

Eric Ignasik: You highlighted how Verto’s commercial strategy influences the roadmap. 

A 2023 report from ProductPlan says most organizations develop products based on business goals rather than customer feedback. 

Which side is Verto on?

I’ve struggled with this question a lot. One school of thought says, “Build it, and they will come.”. This works for consumer markets.

Steve Jobs is a good example of a leader who, I think, followed this philosophy.

If you ask 1000 customers what they want, you might get 1000 different answers. So you can’t develop a product with so many requirements.

You’d have to be lucky to find yourself in the right market and have an accurate business strategy to get the product adopted. Half of the time, you won’t get it right.

I know that if we want to launch a product in a market with a million customers, it has to serve the majority.

Doing favors for end-users is way more effective if they already adopted your product. Saying, “Let me improve this product to improve your current experience,” gives Verto a chance to offer them real value.

Another school of thought centers on analyzing data. It helps Verto discover that what we want to build as a business would serve only five customers.

Sometimes, we notice users log in from a jurisdiction we didn’t build for. We examine the code, make an assumption, and launch a survey to discover what problem they’re trying to solve.

We might realize there are a couple of services we could bundle together to make users from that jurisdiction happy, which would strengthen our growth in the area.

I think it makes sense to shape a product specifically for a popular use scenario if there is enough data to prove it and if it aligns with our business strategy.

`

What are your Product and Engineering departments’ hardest challenges that slow down Verto’s growth?

So, right now, we’re going through an intentional slow-down transition. As we’re focused on enterprise users, Verto needs to start beefing up security, which requires us to produce more documentation pages. 

If we don’t do it, I feel like, in two or three years, Verto can get into trouble if employees leave and take the knowledge of the IP they build.

We built at least 15 digital products. You’d think we’re a team of 500 engineers and product owners, but we’re not.

Our push to document processes is motivated by the fact that every technology or product employee can own a few products end-to-end. You can even be in 3 squads at once.

At Verto, If you are Product Owner (PO) 1 for a product/feature, that is your primary responsibility, so you should understand the product domain by 100%. But for PO 2 or 3, maybe just 50-70% of expertise is acceptable.

Having shared understanding helps us avoid over-relying on one product owner or tech lead. We want to avoid a situation where someone has to say, “Hey, my branch of code is going to touch that, and I don’t know what you’ve done.”.

New people are joining regularly, and it’s getting harder to get them up to speed if a component was built 5 years ago and it’s undocumented.

And I encourage developers to write down everything that needs to be done and validate it with the product owner if they’re working outside of their primary squad to capture everything completely.

Since we’re not a bank, not every spec needs to be registered, but the point is to let people follow your thoughts.

How do you decide which engineering decisions will help Verto continue to grow?

Now, that’s a great question, actually. I think it’s more about the practicality of a decision.

Imagine that Verto started off as a decentralized platform for B2B payment that me and my Co-founder wanted to build on the blockchain. With smart contracting and everything.

That was back in 2017 when blockchain was as hyped as AI today. 

But then, I reflected on the user value. My idea for Verto was realistic, but blockchain didn’t seem to be any better than a regular database. It was actually a glorified database.

And I was a super fan of the cryptocurrency scene.

We wanted to offer faster and cheaper payment processing, which blockchain could support. But it could also be costly if we didn’t build the right infrastructure.

There was this regulatory element in our way. If we needed to plug into an API of a banking partner, they would deny an option to work with the blockchain.

So, with my original assumptions about technology choice, I wouldn’t be able to solve the problem of B2B payments being so slow and time-consuming for companies.

Compared to the blockchain, AI is a game changer for me because we found a practical application for it. 

Some of our customers resolve their tickets with our AI-powered chatbot instead of calling customer support. It’s the right solution for the right time.

It’s okay for us to test an emerging technology behind the scenes to build a proof of concept. And to see if customers love it. 

But Verto doesn’t fall for any hype that says we must adapt something that the market is excited about.

Michael Sols: And may I ask what’s your system for enrolling users into beta tests?

We use several survey types. What’s important is that we ask one question per one login to avoid overwhelming users.

If they continue answering, we might offer them a raffle with an iPad to win for answering a longer survey about the latest release. Even if someone doesn’t need one, it sounds cool.

We might also scope out specific customers from our base to target them with a survey accessible from an email or the main dashboard. Around one in three say “yes”.

Once users complete that initial survey, we ask if they’d like to sign up for a beta. On average, 50-150 people participate.

It’s a win-win for me. We don’t charge them to test a new solution, which they love, and we always create a better iteration for release based on their feedback.

Eric Ignasik: Do you help decide on Verto’s pricing? 

If so, how does the company ensure the prices are good for users and also good for growth?

Since I manage growth marketing for Verto, I am involved with pricing.

For instance, our business account product functions pretty much the same as anywhere else, but our approach to monetizing it is different.

I could argue that our competitors in the UK charge a European customer 20 euros per month, which is too much for an African citizen.

So Verto’s business account works as a lead magnet. It’s free to use forever, and the lack of upfront cost convinces people to sign up. 

Once they need to make a payment or a conversion, Verto charges a fee, but only when the account is actually used.

I would love to just charge for everything, but that’s not the way.

Still, once the customer is in, we can cross-sell a new solution, and pricing becomes way easier to determine.

And that’s the approach. 

But you have to be careful with different markets. In Europe, an option to open a free business account might fail if there are too many choices of such in the market.

Having 50 possible options, the user will think about which brand is the most recognizable.

From the business perspective, it then becomes the game of creating enough touch points for a friend to recommend the account to their network.

Good to remember

What are your 3 rules for other Technology Managers who want to support their teams in building popular software products?

My number one recommendation is that you should know more than what’s within your scope. 

There’s an obviously selfish reason for Verto. Many people can deal with one project.

But it can also work for the employees because we allow them to change between squads.

So you could tell me: “Anthony, I’m tired of this product. I want to move.”. I wouldn’t let you start with 0% expertise, but if you have 50%, the risk of entering a new project is smaller. So carry on.

A lot of the guys who work with me love the concept of open squads because they feel empowered to explore what we do and move around every 6 months.

The second rule I follow is to live by data. It can be misleading, especially if someone throws 50% at you, and you don’t know what is the actual business or user value it represents.

Or somebody might bring about an insight from a survey of 10 customers. Then, I have to explain that we have nearly 5000 of them, so the sample is insignificant. 

The majority won’t like the product that the 10 customers want to have built.

The third rule comes from our time in the Y Combinator —  avoid “things that don’t scale” — which comes from a famous quote by Paul Graham.

Every time we release a new integration or a product, our people get excited and want to automate processes.

And often, I have to ask: “What exactly do you want to automate?”. 

I want you to experience the pain the customer goes through, as it will let you perfect the solution. You should be able to handle copying and pasting for an hour per day to experience their problem first-hand.

I believe a lot of startups get too amazed by the idea of being efficient through automation. Then, when they scale, their automations don’t work for the user.

Nobody developed the right understanding of the pain point first.

Resources

Could you recommend books, podcasts, or courses that taught you the most about leading effective product development teams?

Truthfully, I prefer listening to audiobooks. Recently, I’ve listened to “Die With Zero.”. 

Basically, the book debunks saving money until old age as a clever idea. 

Most people want to live until they’re 70, 80, or 90, right? So imagine if, at that age, you pass your lifetime’s savings to your children, who could be around 20-30 years younger.

They won’t know what to do with that money and will pass it on to the next generation, so the money is useless to them. But who’s getting taxed every time? The money holder.

So, “Die With Zero” suggests passing on wealth earlier, when you’re 40 or 50 years old, to see how it can impact someone’s life before you die.

In the book, Bill Perkins, the author, says he went into banking after graduation. But within the first year or so, he felt like traveling around the world.

His friend from the office warned him that staying at the bank was the best opportunity. But Bill quit anyway and returned a year after, with greater knowledge, while his friend was still stuck in the same position, paying 80% of his salary for the rent and drinking on the weekends.

For me, the story relates to product development. Teams spend enormous time perfecting technology and its front-end textile, but the point is to ship out the software and let users shout at you if they like it or not.

What’s next? Three actions for CTOs to take

Anthony’s decision to enroll each engineer into many squads seems to empower Verto’s ability to develop competitive products.

Development teams that have a shared understanding of how all services interconnect let them organize better around the main roadmap.

Anthony’s most important rules for roadmap management include:

1. protect the goals the team agreed on for the roadmap and question how a feature idea supports the end-user and influences the company’s revenue (that’s how Facebook grew)
2. ask colleagues to draw out the user experience for what they want to build regardless of their design talent — this leads conversations
3.  connect with the growth team to learn how solutions can be designed to encourage sign-ups or engagement, as they also have revenue as their top goal

It’s worth noting that while these points might sound easy, adding them to your company’s cultural DNA can take months.