In a perfect world, features are never reconsidered or modified. In reality, they change significantly as the project is developed, especially with the day-to-day realities of WealthTech. Often, advisors demand new features or investors require integration with the new custodian, but the development team ends up having to fix numerous bugs because these needs haven’t been communicated clearly. The requirements evolved but the team had no clue that modifications were made. As a result, the product is unable to react to market needs in time.
The WealthTech industry evolves much more dynamically compared to other areas, forcing the teams to be as agile as possible. What should teams do to efficiently collect all necessary information about their tasks and stay in sync with the product-management team of a WealthTech project?
- Swati Bairathi (55ip) and her teams hold regular meetings and produce a lot of documentation; they make sure they are communicating in great detail so that people are up to speed on all the different items.
- Matt Pitstone (Riskalyze) has most of the company’s teams split into squads across product lines; each of them has a squad product manager, which makes the work of each squad autonomous.
- Bryson Pouw’s (Blaze Portfolio) tight-knit team of 20 employees is involved in almost all stages of the development process, so that everyone knows everything.
In this article, we will discuss how we solve the communication gap between product and development teams to keep up with the changes and react to advisor demands quickly.
Feature journey from request to production
To ensure there is common ground between product managers and WealthTech teams, it is important to establish overall efficient communication and preempt most of the failures. Common practice is to identify the requirements workflow as the key common ground for developers and product managers. This involves:
- Making clear when requirements are ready to be taken on; making sure that user stories are ready for development, hosted at the top of the backlog, and correctly prioritized.
- Defining criteria for the situations in which requirements can be modified and what product managers should do to notify engineers about changes.
Now, let’s look at how this works in relation to the realities of WealthTech, and how INSART keeps control of the process. The journey starts with an advisor requesting a feature.
| Stage | How we manage it at INSART |
| 1. User story documenting. The feature is described in an unambiguous way, which can take some extra questions off the table and contribute to mutual understanding. |
The industry demands change so dynamically that it’s hardly possible to create robust documentation and keep it relevant. At INSART, we use a storyteam framework to ensure smooth communication between product and development teams. For each feature in the backlog we create a dynamic subteam (a storyteam), which includes all the people who will take part in its implementation: developers, QAs, and product team representatives. The subteam exists only until the story is completed as each feature requires a unique set of skills. One engineer can take part in several subteams at a time. The storyteam members are not allowed to have any one-on-one conversations; everyone should participate in discussions around a given user story to ensure they all have a robust understanding of what needs to be done. |
| 2. Grooming and planning sessions. Grooming entails task prioritization and making sure the tasks are technically feasible. Thus, developers are invited at this stage. |
Let’s say we have a feature request from advisors. The product owner has written the user story. With the team lead, they discuss when it’s best to start working on that feature. Then, the storyteam adds necessary members incrementally so that frontline workers get involved when the requirements are clear. Together they elaborate a plan on next implementation steps, as well as defining the further workflow. Also, the storyteam chooses a duty holder with strong management skills—this condition is crucial for overall framework success. |
| 3. Meetups with product managers. Developers examine user stories in depth and make the details clear. If necessary, they should be able to request additional meetings in order to unpack anything that is unclear. |
The storyteam unveils feature details by asking questions until all the blank spaces have been filled. Once developers have a minimum viable feature prototype, they have another meetup to show the demo to all storyteam members. This takes a little more time for communication, but saves the huge effort necessary in case of rework. |
| 4. Daily meetings. These are used for monitoring working achievements and correcting the focus on the go. |
Under INSART’s storyteams, daily meetings are unnecessary. Instead, storyteams can have several more on-demand meetings if needed. |
| 5. User acceptance testing. Each user story is reviewed by product managers for developers to get feedback on their job. This strengthens their focus on usability and helps them to see the bigger picture. |
The storyteam practices a pretesting adjustment meeting. This aims to ensure that all requirements are met and the feature is ready to be finally tested. They compare the user story description, the developers’ demo, and tests to see whether they’re all consistent. Otherwise, the team risks wasting effort on testing disabled functionality. |
Ultimately, based on the robust implementation process described above, the requested feature is implemented, tested, and ready to be released. The process carries no effort waste and ensures a smooth, predictable workflow.
Takeaways
The storyteam framework aims to tackle the gap between product and development teams in a fast-moving environment. Thanks to this, stakeholders get a predictable implementation process. INSART’s approach enables us to keep up with the WealthTech dynamics and relentlessly deliver quality features.
