How Documentation Enables Collaboration and Compliance for Product Development in a Regulated Bank
- Michael Chernyakov
- Apr 6
- 6 min read
How Documentation Enables Collaboration and Compliance for Product Development in a Regulated Bank
I have changed. I used to disregard documentation, but now I can’t work without it. When starting in product management, you learn about the Agile Manifesto and quickly conclude that you don’t need to invest too much in documentation. After all, it clearly states, “working software over comprehensive documentation.” So, you tell yourself: I’m in a small team, in a relatively small company — who needs documentation? Let’s just talk about it, jot down something simple, develop it, and move on. If something changes, no problem, just leave it as it is. Reinforcing this mindset was the environment,no strict requirements, no escalations, and no real consequences for missing documentation. It simply didn’t matter. Even when we did document more complex solutions, no one ever read them. People preferred asking for an explanation over a quick call or Slack message, even when all the information was already there — all they had to do was click the link I sent them.
All of this changed when I started working with a larger frontend team, 12 developers across iOS, Android, and Web, with dependencies on multiple backend teams in a regulated bank. Clear documentation became crucial. At Solaris, I discovered the power of documentation for alignment. The environment significantly changed the need for high-quality documentation. In a regulated bank, as a financial institution, BaFin outlines documentation requirements in the BAIT (Supervisory Requirements for IT in Financial Institutions). Externally, missing documentation can lead to severe consequences from fines to business restrictions. Internally, it results in misalignment, inefficient development processes, and non-functional solutions.This article highlights the content, goals, and responsibilities of documentation of a banking feature to ensure compliance and facilitate collaboration.
Getting Things Started
Goal: Define a draft of business needs and user requirements to enable initial discussions among key stakeholders, creating a foundation for successful implementation.
Owne: Product Manager or Topic Lead
The process begins with documenting the goal(s), user stories, and any relevant information available (e.g., research, APIs, management presentations, etc.). This draft isn’t necessarily what will be implemented — it’s a starting point for discussion. If everything is correct and agreed upon immediately, great! If not, even better — now we can align, address gaps, and define necessary actions.
The complexity of the feature determines the level of alignment required. For example, a simple feature like a file upload, with no legal implications or interdependencies, requires minimal alignment. However, a new feature like a savings account with interest rates demands design research, competitive analysis, legal and financial considerations, collaboration with several backend teams, and a more extensive alignment process before defining any technical or functional requirements.
Creating a Functional Requirement Document (FRD)
Goal: Define what the feature should do from a user and business perspective and align it with the engineering team.
Owner: Product Team
At this point, around 80% to 90% of business and design requirements are defined. The 10% are smaller tasks that can be done even if development begins such as final content, error messages, minor UI/UX adjustments etc. The following structure of a Functional Requirement Document is prepared by the Product Manager and presented to the teams.
Goal/Problem Statement: What does the feature aim to accomplish?
Flow chart: Diagram representing the workflow and process of the feature.
Description of each step in the flow chart: Detailed description of the user experience requirements which explains each step in the flow chart.
Step user story: I as a user…want to…so that…
Requirements: Requirement around a specific user story
Acceptance criteria: Given…When…Then…
Visual Design: Designed screen for the user story
Other material and information: Links to other materials and information that support the feature
Involved Stakeholders: List of the stakeholders involved or impacted by the feature, level of involvement, tasks & actions needed from the stakeholders. Including stakeholders in the functional requirement document ensures alignment and clear understanding of the requirements and user flow.
Functional Requirement Document Refinement Meeting
The functional requirement document is presented to the teams. We block 1.5 hours each week as a blocker for functional requirement review for 3 teams. If a team is not involved in the feature they do not need to attend, however the meeting is open for everyone. If there are too many topics ongoing the meeting is also cancelled. Engineers generally appreciate fewer meetings.
The meeting’s goal is to collect feedback and explain what we want to achieve with the feature. Any point on the document can be challenged. Backend engineers gain insight into frontend requirements, while frontend engineers understand dependencies on backend deliverables.The review process helps bridge knowledge gaps, identify missing requirements, and refine unclear aspects.
Creating a Technical Requirement Document (TRD)
Goal: Establish a technical agreement between engineers, defining how the feature should work to meet functional requirements.
Owner: Engineering Team
A first draft for the technical requirement document is created by a lead engineer with the knowledge of the functional requirement. The idea of the draft is to create a foundation for a discussion. At this point the functional requirements still are at 80% as technical capabilities might lead to functional requirement changes. Note: not all features have a functional requirement document, in this case the technical requirement document can be a stand alone document. However, when there is a related functional requirement a lot of the information can be connected from the functional requirement document. The technical requirement usually document consists of the following information:
Context & Problem — Describes the background, business need, or challenge that the solution aims to address, providing clarity on why the development effort is necessary.
Requirements — Outlines the key objectives and constraints that the solution must meet, ensuring alignment with business and technical needs.
Functional — Defines what the system should do, detailing features, expected behaviors, and user interactions.
Non-Functional / Technical — Specifies system attributes like performance, security, scalability, and maintainability that impact how the solution operates.
Anti-Goals — Identifies what the solution will not cover or implement, helping to set clear boundaries and manage scope expectations.
Solution Design — Provides a high-level architectural overview of how the solution is structured, including diagrams, workflows, and technology choices.
Section 1 — A placeholder for a detailed sub-section relevant to the specific feature, potentially focusing on a major component or module.
Risks — Highlights potential technical, operational, or business risks associated with the implementation and strategies to mitigate them.
Definition of Success — Establishes measurable criteria to determine whether the project meets its objectives and delivers expected value.
Acceptance Test Scenarios — Lists scenarios that will be used to validate that the system functions correctly and meets its requirements.
High Risk Changes: Additional information applied for high risk changes
Rollout Strategy — Describes how the solution will be deployed, including phases, regions, or user groups involved in the release.
Rollback Strategy — Defines the plan to revert changes in case of deployment failure, minimizing downtime and business impact.
Monitoring Plan — Details how the system will be observed post-deployment to detect performance issues, errors, or security threats.
Impacted Stakeholders — Identifies internal and external parties affected by the feature, ensuring their needs and concerns are considered.
Stories & Tasks — Breaks down the work into development stories and tasks, ensuring clear tracking and implementation in an Agile workflow.
Resources — Lists the tools, teams, documentation, and infrastructure required to execute the project successfully.
Technical Requirement Document Refinement Meeting
In our current structure, in the technical requirement document refinement the engineers align on how they will design the solution to achieve the functional requirements. In larger organisations the backend and frontend teams are separated which leads to differences in design solutions. The first proposed solution might not achieve the best results, therefore the backend and frontend teams need to agree on an implementation. The technical discussion can lead to changes in the functional requirements due to technical limitations or discovering that changes can lead to a much better solution or faster delivery. In the end of the meeting, there needs to be an agreement for the technical implementation from all attending members.
Iteration & When Things Go Wrong
Based on the documents the teams can create their own epics, stories and sub-tasks as needed. It can be that during the development of the feature requirements or technical capabilities change. Therefore, the documentation also needs to be updated and to stay complain changes must be recorded. In organisations where backend and frontend teams work separately, the work starts first in the backend and then the frontend will consume the APIs. This separation of work is where things usually go wrong. Leaving aside team structures pros and cons. Things usually go wrong when there is no time for proper communication due to time constraints, be it delivery demand, vacation, sickness or whatsoever. When changes to APIs are done without alignment and agreement, when the time for implementation comes, there are misalignments. Then, things go wrong, then more time is needed for meetings to re-align and more meetings to review why and where the process went wrong. Therefore, the teams must communicate even when smaller changes and processes for changes are in place. One of the solution we have is a PR for API design which must receive a review from frontend staff engineers before they are pushed.
To Conclude: Ensuring the documentation process is followed is time consuming but enables large teams to work efficiently together and ensure regulations are followed.
Comments