Most software problems start as communication problems
Most software problems I've worked on weren't really software problems at the beginning. They were communication problems: a business process nobody had written down, two teams using the same word differently, or a founder trying to solve three problems with one feature.
I learned this mostly through ERP work. In a cooperative society, a word like "member" or "loan" sounds settled until you ask the finance team and the field staff to define it separately. The software can't be clearer than the shared understanding behind it.
So when people say collaboration matters, I agree, but I mean something narrower and more practical than the usual version. I don't mean more meetings or a bigger team. I mean three habits that keep the people who know the business and the people who build the software talking about the same thing:
- Write the workflow down before designing the screen.
- Agree on definitions for the ten or so words that matter most.
- Show working software early, because people react to a screen far more honestly than to a document.
1. Write the workflow down before designing the screen
Ask someone how a process works and you'll get the version they'd put in a manual. Watch them do it and you'll see the real one: the second spreadsheet, the manager who signs off by phone, the step that only happens at month-end.
The gap between those two versions is where most rework comes from. If the software follows the manual, people work around it. If it follows the real process, including the awkward parts, they use it.
Before anyone designs a screen, I want a plain written description of the workflow as it actually runs. It doesn't need a diagramming tool. A numbered list is enough, as long as every step answers four questions:
- Who does this step?
- What information do they need to do it?
- What do they produce, and who uses it next?
- What happens when it goes wrong?
That last question matters most. The exceptions are usually where the business rules live, and they're the part nobody mentions until the system is in use.
How to start next week: pick one process your new system has to support. Sit with the person who does it, not the person who manages it, and write the steps down while they work. Then read it back to them and fix what you got wrong.
2. Agree on definitions for the words that matter
Every organization has a handful of nouns that everything else depends on. In an ERP system they're things like customer, member, invoice, stock, period and approval. In a marketplace they might be listing, booking, verified and available.
These words feel obvious, which is exactly why nobody defines them. Then one team counts a customer as anyone who has ever bought something, another counts only active accounts, and a report that both teams rely on is wrong for both of them.
A short glossary fixes more of this than any amount of specification. For each important word, write one or two sentences: what it means, what it doesn't include, and who owns the definition. Keep it somewhere both the business side and the engineers will actually read it, and use the same words in the database, the interface and the reports.
How to start next week: list the ten words that appear most often in your requirements or meetings. Ask two people from different teams to define each one separately. Wherever their answers differ, you've found a future bug.
3. Show working software early
People can't review a document the way they review a screen. A specification gets polite agreement. A working screen, even a rough one, gets "that's not how we do it" within a minute. That's the feedback you want, and you want it before the design is expensive to change.
So I'd rather show something small and real every week or two than something complete after three months. The first version doesn't need to be pretty. It needs to use real data, follow the real workflow and let people try it.
This also changes the conversation. Instead of debating what a feature should do in the abstract, everyone is reacting to the same thing on the same screen. Disagreements surface early, while they're still cheap.
How to start next week: take the workflow you wrote down in step one and build the thinnest version that lets one person complete it end to end. Put it in front of that person and watch them use it without helping.
What this isn't
None of this needs a big process. It doesn't need a new tool, a workshop or a full-time analyst. It needs someone on the project who's willing to ask obvious questions and write the answers down.
That someone is often the engineer. The people who build the system are the ones who have to turn vague language into exact rules, so they notice the gaps first. The best thing they can do with that is say so early, in plain words, to the people who know the business.
If you're planning a system and want a second opinion on the workflow before you build it, that's the kind of work I help with.