A few years ago, I was working at a fintech company in Germany. Our business unit planned to build a new offering for customers in Germany and the UK.
Our team — product owner, business analyst, developers, and QA — gathered at a location and ran brainstorming sessions.
Since we were also using the product ourselves, we were essentially both the builders and the end users.
After a full day of discussions, we collectively came up with a list of features for the first MVP.
The BA took brief notes, and later, together with the developers, prepared JIRA cards for all those features.
We then expanded on the requirements to flesh out the use case details and added acceptance criteria.
In that company, we (developers) worked closely with the product owner and BA throughout the entire requirements process.

SivaLabs

A reflection on the importance of curiosity over judgment in software development contexts. Using examples from different organizational cultures — fintech, banking, and solo SaaS — the author argues that developers should resist assuming their way of working is the only valid approach. The post uses a LinkedIn debate about code quality in the AI era as a case study, advocating for asking questions to understand differing perspectives rather than dismissing them. It closes with a broader point about staying open to experimentation while remaining grounded in fundamentals, especially as AI-assisted development reshapes the industry.

Before You Judge, Get Curious