RSVP FOR FREE | How Carpe Data Supercharges Roadmap Planning to Deliver Outcomes | Oct 3 @ 9 AM PT


How the Struggle to Connect Strategy and Execution Led to the Start of Dragonboat

In May 2017, I joined a Fintech startup, Feedzai,  to build its first product organization and create the product management best practices that connect strategy and execution: customer needs, business goals (OKRs), and long-term product strategies responsively.

Challenges From Rapid Growth

When I joined Feedzai, it was in super growth mode, from ~100 people to 300+ in about a year.

As the customer base expanded, it created a much wider roadmap intake funnel influenced by current customers, prospects, internal teams, and market insights. As a result, the engineering team grew, which formed more scrum teams. Before long, most features started to require multiple scrum teams. Dependencies started to slow everyone down.

Planning and executing on the same 2 week cadence no longer works in growing companies.

– CTO, Feedzai

Teams were busy, while business units didn’t get what they want. There were scrum and sprint metrics but no big picture visibility. No one could answer these 3 basic questions without some effort of digging:

  • What features will we launch next month? Why?
  • What does it take to add this critical feature in the coming release? 
  • Which team and skills do we need to hire next? How do we decide?

We also had gaps and misunderstandings between various departments, e.g. Product, Marketing, Sales, and Support as there wasn’t an end-to-end view of bringing the product to the hands of customers.

The Basics

During my first 2 months, I built an end-to-end PDLC process (Product Development Life Cycle) from idea intake and alignment to strategic prioritization, agile development, and go-to-market. 

To support these processes, I reconfigured Jira, instituted quarterly and rolling roadmap planning and tracking cadences, and built 4 spreadsheets to manage ideas, product planning, resourcing scenarios, team assignment, and rolling planning (current period execution and next period discovery in parallel).

I made these changes quite quickly, as Feedzai was the 4th growth company I went through this type of transformation with. There were some slight tweaks partnering with product and engineering teams, of course.

The framework, Jira optimization, and a suite of spreadsheets enabled us to plan strategically, flow through to execution, and adjust our plan when new things come to our roadmap. We could now connect strategy and execution but with a lot of effort and meticulous record-keeping and syncing by product managers, engineering managers, and Project managers/ scrum masters. On average, each spent 2 or more days per week on updating spreadsheets, syncing data in different tools, and writing various status updates.

While this sounds challenging, it is not quite unique.

We Needed a Better Tool

A growing company needs to adjust focus frequently – both on the product front as well as the team and resource front. This requires overall visibility, and the ability to re-align initiatives and resources quickly to respond to changes.

However, planning is painful. It takes a lot of time to iterate through various roadmap options within the constraint of resources, timeline, and dependencies (see Build A Better Execution Roadmap). This gets exponentially more complex when the company gets bigger. If a feature requires 2–3 teams or skills, and there are 10+ teams, the permutation combination can get out of control very quickly. At most, we do 2–3 iterations of roadmap options and quit then. We simply run out of energy and time to find the best combination. And even if we’ve “locked down” the upcoming roadmap (next month or quarter), things change… and the pain will start all over again.

While many companies practice big picture planning (connect strategy and execution) to complement agile execution, the way we manage this process has not changed for 20 years.

Spreadsheet + meetings + presentation is still how most teams connect the dots between strategy and execution.

The Lightbulb Moment

In the preceding 3 years, I’ve been on several tool hunts, tried and used dozens of roadmap and project portfolio tools, including Aha!, Portfolio for Jira, Roadmunk, Product Plan, Airtable, Trello (on steroids), Smartsheet, Asana, Monday (back then it was called Dapulse) and even “old school” tools like Planview and Clarity (CA PPM). I also did many interviews with many Product, PMO, and engineering leaders. There was no modern tool to connect strategy and execution and enable cross-functional collaboration.

When 2 engineering leaders from 2 different companies reached out for suggestions on a “better spreadsheet” to manage their roadmaps and resources… I realized they didn’t need a better spreadsheet, they needed an intelligent system to connect strategy and execution and support iterative planning to respond to changes quickly.

I decided to build one – This is the start of Dragonboat – the smart, complete, and Responsive Product Portfolio platform to help companies build better products and teams.

Series A CTA

6 Elements of An Execution Roadmap

An execution roadmap is the plan that brings your company’s strategy to life.

Intentionally or not, every company follows an execution roadmap, where teams allocate time, i.e. resources, to execute against a list of initiatives in a certain order.

Building an execution roadmap typically starts with setting priorities. Many product prioritization frameworks and tools are built to allow easy ranking of feature priorities. Your team works  through this list of priorities and delivers features to the market. This works quite well when most work is done exclusively within an agile team.

As the company grows, it will have multiple product managers and multiple teams. Often one product manager needs other teams and other product managers to support her features.

When this happens, a friendly negotiation may settle the request. Sometimes though, the competing demands need a mediator, often the engineering manager of the team. The inevitable question usually is, which feature/ story has a higher priority. It seems that once we get our priority straight, the roadmap will fall into place effortlessly.

That’s what I thought too, earlier in my career… Back then, our engineering team supported both our “home” product managers and product managers from other business areas. Often there were back and forth debates on which projects are higher priority. Since they came from different groups, it was harder to gauge one group’s metric (priority) against the other group’s. Out of frustration, I wondered why the CEO or the head of product can’t just define priority for the entire company, from 1 to n. Then the team can just build them out in sequence and produce the best results for the company….

Or so I thought… but this approach fails everyone!

First off, no one person can/ should define the fine-grain level list of features for the entire company, let alone prioritizing all of them. This type of micromanagement, assuming everything is known ahead of time, is dangerous. Leaders should focus on defining strategic problems (setting strategic goals), not dictating the solutions and sequences.


Factors to Consider When You Build an Execution Roadmap

Even if we can define product priority, here are still several key factors to consider when you build your execution roadmap.

Impact indicates the level of benefits towards your strategic goals.

Effort (or Opportunity Cost)
High impact and high effort initiatives may not produce better market/ customer results than a few lower impact but much smaller effort initiatives combined. Since hiring and ramping up takes a long lead time, effort indicates opportunity cost that should be evaluated thoughtfully.

Resources (Non-fungible Skillset)
There are different skill sets within a team e.g. frontend, backend, DevOps, QA, UX… demand for each skillset fluctuates and differs from the actual distribution of skills. If a company adopts resource forecasting (often on the quarterly or semi-annual frequency), a temporary skillset balance between teams may be adopted to improve portfolio output, instead of having an un-utilized skillset for one team to take on less impactful projects while another team has to take fewer projects due to skillset constraints.

Skillset limitation also creates a new dimension to the opportunity cost.

Dependencies (or Readiness)
No one likes to be blocked… one of the most common blocking factors is when there is a dependency, either unplanned or known but poorly coordinated.

For example, there is “hurry up and wait” as you are ready, but your partner is not. Or your team can’t start because they are waiting for upper stream deliverables, e.g. user research and prototype validation.

Deadlines (or Quick Wins)
Some relatively lower priority features can be desired/ demanded by customers or required by legal… launching them on time needs some planning ahead in your execution roadmap.

Time in Market
Often it’s better to iteratively build, releasing and testing parts of a feature before the final release. Allowing time in market for feedback before building the next phase is the right way to build product… Team should use the gap to work on other features or address tech debt.


Building a good execution roadmap needs to consider all these factors. However, the process does not need to be a drawn out one that requires all the “facts and figures”. There is no perfect information on any of these factors. Create a draft, try it out, iterate as you get more information.

This site uses cookies. Some of these cookies are essential, while others help us to improve your experience by providing insights into how the site is being used. For more information, please check our Privacy Policy. You can disable or remove cookies in your browser settings at any time. By clicking "Accept" or continuing to use this site, you consent to our use of cookies across the site.