Be honest: When was the last time your project failed because PostgreSQL couldn't store data fast enough? Or because React couldn't render a button?
Probably never.
We see it time and again: Technically, everything works. The team is motivated. But in the end, there's a piece of software that nobody really wants to use. Or one that maps processes that don't even exist in real life.
The problem is rarely the tools. Frameworks work, cloud platforms scale.
The problem is almost always: We didn't understand what problem we're actually trying to solve.
Requirements Engineering often sounds like tedious documentation work. For us at vensas, it's something else entirely: It's the process of turning a vague problem into a working system.
Ditch the Feature List
The classic project kickoff: Someone shows up with an Excel spreadsheet full of features. "User management", "PDF export", "Dark Mode".
It feels productive, but it's often the first step in the wrong direction. Features describe a solution, often before the problem is even clear.
That's why we usually start differently. We look for the use case in the real world.
- Who is actually sitting in front of the screen?
- What is this person trying to achieve?
- Where does their current workflow break down?
We don't want to build hypothetical features ("It would be cool if you could also export it as Excel"), but solve real problems.
The result isn't a feature list, but a core use case. A story that describes how the software makes a user's life better.
The Early Vertical Slice
Instead of spending weeks writing concepts and drawing database diagrams, we aim for a vertical slice as early as possible.
What does that mean in practice?
We don't build a complete login, a finished database architecture, or a polished design. We build a single, narrow path through the system that works.
Imagine you're building a web shop. The vertical slice wouldn't be the shopping cart or the product search. It might be:
- A static page with a "Buy" button.
- The user clicks it.
- The server receives the click.
- An entry is created in the database ("Order #1").
Sounds trivial? It is. But here's what we prove:
- Deployment to the real environment ("Production") works.
- Frontend and backend can talk to each other.
- The database connection is up.
Once this path is in place, the biggest technical risks ("We can't get this system live") are off the table. From here, we can focus entirely on the business logic. A small working slice creates more clarity than a 40-page specification.
80/20: Focus on the Core
In every system, there's that one process that delivers 80% of the value. Maybe it's the quick checkout in the shop. Or the appointment entry in a calendar app.
Everything else – password reset, profile picture changes, invoice archive – is important, but not critical for the launch.
We try to focus radically on this core use case. If it works and helps real users, we've won. The rest is legwork.
If you try to solve everything at once, you often end up solving nothing properly.
Sounds logical? In practice, it's one of the hardest disciplines. We also keep falling into the trap of getting lost in details before the core is solid.
Need Support?
Do you feel like your team is discussing features more than actual problems? We'll help you regain focus. Let's sharpen your core use case together and plan the first vertical slice. Just reach out.
In the next part of this series, we'll look at how to keep this process running in an iterative cycle – without descending into chaos.