Architecture decisions are made with incomplete information. Pretending otherwise produces documents that sound confident and systems that can't adapt. In my experience, most of that uncertainty doesn't come from the technology. It comes from not understanding the problem well enough before the design work starts.
Problem Statement
When a business use case lands on a team, the reflex is to start solving it. Within minutes people are talking about endpoints, tables, and which service should own what. What gets skipped is the problem itself: who the user is, what they need, and whether the use case as written is even feasible.
A use case can arrive in very different shapes. It can be well thought out and ready to build. It can be the product manager's line of reasoning toward a solution that doesn't quite solve the problem. Or it can carry far more complexity than the simple thing it's trying to fix. Each of these needs a different response, and you can't tell them apart without digging.
On top of that, teams still have to make consequential technical decisions before they have good data about scale, product direction, hiring, cost, and operational maturity.
Where Teams Usually Get It Wrong
The first mistake is jumping from the use case straight to the implementation without asking whether the use case is right. The design that follows can be excellent and still solve the wrong problem, or solve a simple problem in a complicated way.
The second mistake shows up once the problem is clear: teams either over-design for imagined futures or under-design because the current system still works.
Principles
- Understand the problem before designing the solution.
- Question the use case, including the reasoning behind it.
- State constraints before preferences.
- Separate reversible and irreversible decisions.
- Optimize for the next learning point.
- Record rejected options.
- Make the cost of being wrong visible.
Decision Model
The chart has two stages. The first decides whether the problem is worth solving in the shape it arrived. The second decides how to solve it and keeps checking that decision after it ships.
Use case arrives
I start here before the work formally reaches me. Once a ticket is assigned, the team is already thinking about the implementation, and questions about the use case start to feel like a delay.
Understand the problem
Who is the user, and what are they trying to do? The goal is to describe the problem in plain words, without mentioning endpoints, tables, or services.
Explore alternatives
Look for other ways to reach the same outcome. The proposed flow is often one person's path toward a solution, and a different path can be simpler.
Is the use case sound?
Four checks decide it:
- It's feasible as written.
- It solves the real problem.
- Its complexity fits the problem.
- It matches the real intention behind the request.
Business design issue
If any check fails, the problem is in the business design, not in the architecture. Take it back to product with what you found, and start over when the revised use case comes back. No technical work starts on this branch.
What is the decision's reach?
Once the use case is ready to go, the next question is how far the decision reaches. The answer picks the document.
Write an RFC
An RFC is for establishing architecture across a large ecosystem. The decision affects several teams, services, or consumers, shapes what they depend on, and needs their input before anyone commits to it.
Write an ADR
An ADR is for something built from scratch, like a new service or a new feature, where the change doesn't break anything that already exists. It records the context, the decision, and the options I rejected, so the reasoning is still there when someone asks about it later.
Frame the decision
Whichever document it is, the decision fits on one page and names eight things: context, constraints, options, tradeoffs, risk, reversibility, the triggers that would reopen it, and its owner.
Compare and commit
Compare two serious options and one rejected option, and define the first rollback point before committing.
Ship and watch
The decision isn't finished when it ships. Wait for the first production signal before treating it as settled.
Does the decision still hold?
Review the decision against that signal and against the triggers named in the frame. If a trigger is hit, go back to framing the decision with what you learned. If not, the decision stands until the next review date or trigger.
Practical Defaults
Keep the documents short, name assumptions directly, and attach review dates or trigger conditions to decisions with high uncertainty.
Tradeoffs
Questioning a use case takes time, and it can feel like friction to a product manager who already has a plan. Skipping that step tends to cost more, because the bill arrives later as rework on something that shouldn't have been built that way.
The same balance applies to the documents. A heavier decision process can slow teams down, and a lighter one can hide important tradeoffs. An RFC for a change inside one service is overhead. An ADR for a change that reshapes a whole ecosystem is not enough.
Example Workflow
- Before the use case is formally handed over, read it and talk to whoever wrote it about the user and the problem.
- Explore at least one other way to reach the same outcome.
- Decide whether it's a business design issue or ready to go. If it's a design issue, take it back to product before any technical work starts.
- Pick the format: an RFC if the decision shapes the wider ecosystem, an ADR if it's a new service or a non-breaking feature.
- Write a one-page decision frame, compare two serious options and one rejected option, and define the first rollback point.
- Review the decision after the first production signal.
Checklist
- The user and the problem are described in plain words.
- The use case was challenged and alternatives were considered.
- It's clear whether this is a business design issue or ready to go.
- The format fits the reach of the decision: RFC or ADR.
- Constraints are explicit.
- Reversibility is classified.
- Rejected options are named.
- The first production signal is defined.
- A decision owner is named.
Related Playbooks
- Designing backend boundaries that survive production pressure
- Testing and delivery practices that protect momentum
Bring This To Your Team
This topic works well as training for teams that need better architecture reviews, a working ADR and RFC practice, or a better way to push back on use cases before building them.