Right things in the right way. A fintech startup case study from a Product Owner’s perspective

At the core of our brand lies a passion for delivering the right solutions most effectively. Let me share one of the many successful projects we have completed. It was a challenging one; however, I am thrilled to say that the results we achieved exceeded all expectations.

This is a story of:

• Why you shouldn’t put estimates before your project’s outcomes;
• How user story mapping can help you reduce project scope by 90% and avoid generating waste with unnecessary features;
• What’s the role of Product Owners, and why it’s crucial you have one in your project.

Problem: Analyzing real-time payments worldwide is hard

Let’s start the story with a question:

• What could be the cost of developing an app that analyzes all worldwide real-time transactions (and payment rejections) of businesses like Carrefour or Zara? 

Imagine this: a customer goes shopping at Zara and pays with a card, but… the transaction doesn’t go through. So 5% of customers leave the shop, and Zara loses their shopping baskets. These 5% might not seem like a lot. But if you look at it globally, it turns out that 5% of customers abandoning their shopping carts due to failed transactions can make quite a significant financial loss!

One of our clients saw a possibility in this situation.

Idea: Let’s simplify payment analytics with an app

Our client was a financial consultant helping companies like Carrefour or Zara to optimize their transactions. The problem is that they probably used some rather “old-school,” not scalable tools (PowerBI, for example). As you can imagine, it wasn’t very effective.

To make this process more productive, we were supposed to create an app that could keep track of Zara, Carrefour, and other merchants’ financial transactions in different countries and from various payment providers, simplify the payment data, and provide a detailed analysis that could help them spot common issues (like this 5% of abandoned shopping carts) and fix them.

• But… how much would it cost?

15 million dollars?

2 million dollars?

The client asked us the exact same question.

Client comes to us. They need budget estimations

The client came to us with a list of requirements and wanted us to estimate the cost of building such an app.

I asked them the standard question I ask every client:

• Why do you need exact estimations? 

This is an excellent test to understand what our contribution as a software development partner will be in a particular case. Our company wants to be something other than just a code patcher. So when a client comes to us and says: “stick to our guidelines,” we reject doing it this way without first understanding what their real goals and motivations are.

We can deliver the product, but we can’t give them the estimates

We conducted a product discovery workshop for the client to see what we could do and how we could contribute to the project. To do that, we used the use story mapping technique by Jeff Patton.

User story mapping

When a client comes to me and says: “This is the Figma project I made; this is the backlog I made; how much will it cost to build a product based on them?” I often do user story mapping. We discuss the client’s target audience, their problems and needs, and the outcomes their product will generate.

We pick three of these outcomes that will make the most significant impact, write them down on sticky notes, and put them on the wall. The assumption is simple: if these three things are the most important and can make a tremendous change, then when developing a product, we should focus on them first.

These three notes are usually 10% of all the sticky notes in our user story map. And the message that comes out of that is that by choosing them and eliminating the rest, I have just reduced the project scope for the client by 90% and saved their money.

At Pragmatic Coders, we have a saying that the scope a Product Owner throws away is the criteria by which you would judge them.

Client leaves

The workshop let us build rapport and understanding with our client. We defined the market and chose the segments with the lowest entry threshold they could start with. We gave them a strategy draft – they knew precisely in what order to deliver product features to get funding (or at least boost their chances).

Unfortunately, after this three-day workshop, the client left us very dissatisfied. Why? They didn’t get a quote. We defined the project scope and knew exactly what we needed to do to deliver the product. Still, we couldn’t tell them how much this project would cost because of too many variables.

That was the end of our cooperation… at least for that time.

Client comes back

They turned to other software development providers asking for estimates.

The estimates varied A LOT. And sure, all these valuations could be true. But they could have nothing to do with reality as well.

The client came back to us after three months. Again, we could not tell how much the project would cost them. Still, they trusted us anyway because they knew we focused on delivering value and would challenge anything they came to us with to make sure we developed only what would be profitable for them.

So we started talking about strategy. And that “strategy talk” helped answer the question:

• How do we want to deliver this project?

To give you a hint about the client’s budget: they didn’t have 15 million; they didn’t even have these 2 million dollars. They needed more money from investors.

We assumed that if VCs see a mock-up that looks great, works, and lets users save money- they will believe in it. And if they invest, maybe not 15, but a few million – we will refine this solution because we proved we could develop it.

Why was a Product Owner necessary?

My goal was to deliver value by helping the client save money while still building a high-quality solution.

I was there to:

• Ensure that the client’s money would not be wasted;
• Make developers know what problem we wanted to solve with the product and what we were working toward;
• Use the insights from the UX research to ensure the mock-ups we were about to prepare and the product based on them would be exactly the product they would later like to pay for.

What would it look like without a Product Owner?

I think that if there had been no Product Owner and the client had not come to us, they would have found a company that would have done it for half a million USD. I am not sure that the product shown to investors afterward would have had such a value, though.

Why?

Our client’s main goal was to create something they could show to investors, get the right first round of financing and then build the right product. At that stage, they didn’t worry about making a complete working app, so spending as little money as possible was their priority, and we addressed this need.

In this case, I could help the client spend only about 80,000 USD by finding a more cost-effective solution.

Results

Quick summary: we conducted a workshop, then had a 3-month break, during which the client did a world tour looking for budget estimates. Then they came back to us, and we finally created a fully-functional product in 3 months. Done. Three months of development cost them about 80,000 USD, not 1, 2, or 15 million.

Lessons learned

Here are 5 insights you can take from the story I just told:

• Understanding the client’s needs and goals is crucial: This helps develop a strategy tailored to the client’s specific situation and budget.
• Communication and collaboration are key: Conducting a workshop and using tools like user story mapping and market analysis can help build a deeper understanding of the client’s needs and priorities, which leads to better communication and collaboration.
• A prototype can be a powerful tool: in many cases, creating a cheap mock-up is enough to get funding from investors. You don’t need to develop a complete product straightaway.
• Estimation should not be the primary goal: The goal of asking the client why they need estimation is to understand the purpose and motivation behind their request. By focusing on the change you want to make with your product, not on your product’s features, you can prioritize better.
• Be flexible and adaptable: In an unpredictable world, it is essential to be flexible and adaptable to provide the best solution for the client. By taking the time to understand the client’s needs and developing a customized strategy, we were able to provide a solution that was feasible and in line with the client’s goals and resources.