Your engineering managers have provided their initial estimates for your fintech feature.

They look something like this:

• Mobile app development: 2–3 months
• Microservices changes: 1 month
• Call routing updates: A few weeks

These are high-level estimates.

Engineering managers typically estimate based on the team’s experience, current capacity, and similar features delivered in the past.

That’s normal.

But here’s the problem.

They don’t see every nuance involved in building this specific feature.

They’re not thinking about things like:

• Edge cases in the UI
• Missing API fields
• Analytics integration
• Testing scope in each sprint

So who helps you understand those nuances?

Your core team.

Who is your core team?

Your core team is the group of individual contributors who will actually build the feature.

They include developers and testers from the following teams :

• App development
• Backend (microservices) development
• Database engineering
• Data engineering
• IVR development (as call routing is involved)

They report directly to the engineering managers.

Your job is to work with them directly, break the work into smaller chunks, and give leadership realistic timelines.

Let’s see how to do that.

Step 1: Give context before estimating

Before you talk about timelines, walk your core team through the Product Blueprint. Show them who is churning, what problem you’re solving, why this feature exists, and what the final designs look like.

When developers understand the business problem, they think differently. They identify edge cases earlier, question assumptions, and anticipate risks.

They are also more motivated because they see the bigger picture.

Step 2: Prepare your timeline estimation sheet

Before meeting with each team, prepare your planning sheet.

Here’s what it looks like.

The sheet has sprints along the top and teams along the side.

A sprint is a fixed time period, usually two weeks, during which a team commits to completing a defined chunk of work.

Always estimate using working days, not calendar days. Two weeks typically means 10 working days.

Each team is color-coded in the sheet. When you capture a dependency, you highlight it in that team’s color so it’s immediately clear who is waiting on what. This makes dependencies visible rather than buried in meeting notes.

Step 3: Meet with each team separately

You schedule separate estimation sessions with each team.

Let’s start with the mobile app team.

You show the iOS and Android teams the final design and ask:

“If you were building this screen, what would you build first? What would you build next?”

You ask both developers and testers this question together.

They might respond like this:

• Sprint 1: Build layout
• Sprint 2: Add buttons and interactions
• Sprint 3: Integrate backend API
• Sprint 4: Add analytics tracking

Developers and testers give you one combined estimate per sprint that includes both build time and testing time.

Each sprint must end with something that is both built and tested.

If a sprint has 10 working days, developers might build for 7 days and testers might need 3 days. Testing is not extra time after the sprint. It is part of the sprint.

At the end of each sprint, you demo the completed work to stakeholders. It’s a great way to communicate progress and keep everyone aligned.

As you can see in the sheet, this is also where dependencies get captured. For example, the mobile app team needs analytics codes before Sprint 3 starts. You add that to the “Dependency” row and color-code it to match the mobile app team.

You’ll also notice in the sheet that the later sprints have capacity reserved for higher environment testing and pre-launch. This is important. Higher environments are where the mobile app and all the backend systems connect and get tested together. Pre-launch is where pilot users test the feature before it goes live. Defects will come up in both stages. If you don’t reserve capacity to fix them, your timeline will quietly extend.

Backend, data, database, and call routing teams

You repeat the same process with:

• Backend (microservices) engineers
• Data engineers
• Database engineers
• Call routing (IVR) developers

We covered what each of these teams does in the previous article, so we won’t go through them again here. The process is the same: ask what they would build first, slot it into sprints, and capture any dependencies. All of it gets added to the sheet.

One final alignment meeting

Once you’ve completed the estimation sessions with every team, you schedule one final meeting with your entire core team and their engineering managers.

You walk everyone through the sheet and call out the dependencies between teams. The goal is to make sure everyone is aligned. If the engineering managers’ estimates are too far off from what the core team estimated, that needs to be discussed and resolved in the room.

You communicate timelines to leadership only after everyone is aligned.

Add a buffer to your timeline

A timeline is always an educated guess.

The accuracy of that guess depends on two things. How skilled the developers are. And whether they’ve built something similar before. If the team has done this kind of work before, their estimates will be more accurate. If not, they might need to run a quick proof of concept first, as we saw earlier, to arrive at a rough estimate.

That’s exactly why you add a buffer.

Add two to three sprints depending on the complexity of the feature. Something always comes up in software delivery. No matter how carefully you plan, something can shift during development. Buffer is what protects your timeline when things change.

Present to leadership and get alignment

Once you’ve finalized the timeline with your core team and engineering managers, you present it to leadership.

This is similar to how you presented the Product Blueprint, the wireframes, and the metrics framework. You walk leadership through the timeline, explain how the work is broken down into sprints, and show where dependencies exist.

Get alignment in this meeting. If leadership has questions or concerns about the timeline, you need to address them now before development starts.

Only after you have alignment do you move to the next step: starting development.

From rough estimates to a credible timeline

You started with rough estimates from your engineering managers.

Then you worked closely with each team to break the work into smaller chunks and slot everything into sprints. You captured dependencies and reserved capacity for higher environment testing and pre-launch. You added a buffer because something always comes up during software delivery. And you presented the timeline to leadership and got their alignment.

All of it is documented in one sheet.

This marks the end of Piece 4 of the fintech puzzle: The Solution Build.

Before development starts, you update Piece 4 of the Product Blueprint with the delivery timeline sheet and the KPIs you defined earlier.

Once the teams start building, your job is to guide them through each sprint as they complete their work. At the end of each sprint, you demo the completed work to key stakeholders. Usually, someone from the leadership team represents those demos. You track progress, resolve blockers, and ensure dependencies are met on time.

The next phase is Piece 5 of the fintech puzzle, Launch and Iteration. That’s where we’ll look at what activities to do pre-launch and post-launch.