From 1,500 Requirements to Product Strategy Designing a Cohesive System Through Data, Flows, and Integrations
In complex, regulated environments, the challenge is what comes after creating your requirements.
In this project, I had already mapped the system end-to-end, organized requirements across operational domains, and captured hundreds (well, thousands) constraints and details. However, I despite this documentation, we still had the possibility of dealing with fragmented workflows, inconsistent data, and systems that don’t work together: oops! the very problems we were trying to solve in the first place!
Here’s the gap: the requirements didn’t tell me how the system works
The requirements described what each part of the business needs, and what must be supported for compliance and operations.
And here’s what they didn’t answer:
How the data moved across the system
How the systems interact in real time (or batch time :) )
Where ownership lives
In this complex ecosystem, this immediately created a risk of everything breaking at these seams.
Here’s what I did
Part 1: Break out of domain thinking and follow the data
I appreciated using the domains for organization because it was easy to manage problem definitions and stakeholders throughout the progress. But, by prioritizing that story, I obscured how the system became defined by data flows.
We learned some incredible insights:
The same data was still being recreated across multiple systems
No consistent source of truth for critical entities
Manual reconciliation required to fix mismatches
These stung, because we already saw these issues on the user workflow side, but then also found them on the technical side.
Part 2: Identify integration as the product
After learning about additional system architecture needs, requirements needed a rework.
We had deeper discussions about what’s possible, what’s scalable, and what’s maintainable. This was about creating an entire seamless ecosystem between new user workflows and system architecture.
Some of the questions we asked were:
Where does data originate?
Who owns it?
How is it updated, validated, and consumed?
What happens if a part of it fails?
I was thankful to have a strong working relationship with engineering to go through the work of getting on the same page here. These directly impacted how I made product decisions and tradeoffs going forward.
Part 3: Mapping and strategizing
As we moved through mapping and decision making, we focused on:
Defining APIs and data contracts between systems
Establishing ownership of data identities
Mapping movements that would survive across multiple tools
Defining data migration into the roadmap
Part 4: Putting it all together
We really shifted towards more comprehensive problem solving as a team. We went from asking what features each domain needs, to what flows need to work end-to-end. I overlayed our new user workflows over our data map like croissant layers, each layer adding a new level of richness.
At this point - voila! - requirements became less overwhelming. We were no longer evaluating them individually and getting bogged down in Jira management.
Instead, we were asking questions such as:
Does this support the data model?
Does this align with defined system workflows?
Does this strengthen or weak integration points?
What else is dependent on this integration?
Where are the most risks?
We were able to standardize data models, invest in API-driven integrations, and orchestrate workflows across systems.
Ultimately, we had a cohesive platform that allowed us to scale as the company continued to grow.
What I’d do differently
Invest in deeper technical discovery earlier
Many of the most important architectural and integration challenges didn't emerge until we were already well into delivery. While we eventually uncovered and addressed them, earlier involvement from engineering and deeper technical reviews could have exposed some of these risks sooner.
In future projects, I would spend more time upfront mapping system dependencies, integration constraints, data ownership, and architectural assumptions before finalizing large portions of the delivery plan. Not because the original requirements were wrong, but because understanding the technical ecosystem earlier would have allowed us to make more informed decisions and reduce rework later.
Focus on outcomes before solutions
Because we were operating in a highly regulated environment, documenting requirements thoroughly was critical. We needed to ensure operational details were captured, compliance obligations were addressed, and stakeholders could see that their needs were represented.
That diligence was valuable.
However, in some areas, we became so focused on documenting detailed solutions that we limited our ability to explore alternative approaches with the vendor. We often arrived at conversations with proposed implementations rather than starting with the underlying business problem and desired outcome.
If I were approaching the project again, I would spend more time defining workflows, constraints, business objectives, and success criteria while remaining intentionally flexible about how those needs would ultimately be solved. This would have created more opportunities to leverage vendor expertise, evaluate alternatives, and adapt as we learned more about the platform.
The requirements were necessary. The lesson was that comprehensive documentation and strategic flexibility are not mutually exclusive. The challenge is finding the balance between being thorough enough to protect the business and flexible enough to discover better solutions along the way.