Questions before redrawing architecture for a better map

Why redraws go wrong

Most architecture redraws fail before anyone opens a diagram tool. A team gets into one workshop, sketches a clean flow, and agrees a little too quickly. Real work is never that neat.

The same workflow creates different pain for different teams. Product sees delays and missed scope. Support sees repeat tickets, strange edge cases, and confused customers. Sales notices where deals slow down because a feature is hard to explain or setup looks risky. Ops sees failed jobs, fragile integrations, and manual fixes that never show up in planning.

Put all of those people in one room and the quieter problems usually disappear. Support and ops often carry the expensive details, but they do not always win the room. A louder team can pull the map toward its own problems even when the larger cost sits somewhere else.

Old diagrams make this worse. Many of them follow the org chart instead of the work itself. They show teams, systems, and ownership boxes, but miss the real path of an order, a ticket, a refund, or a failed sync. The result looks tidy and still leads to a bad redesign.

That is where architecture work starts to drift. The map begins to reflect who talks most, who owns the budget, or who built the first version years ago. It stops reflecting where the pressure really is.

If you want an honest picture, talk to teams separately before you redraw anything. Individual interviews work better than a shared workshop because each team explains the same flow from its own daily pain.

Who to interview

Start with product, support, sales, and ops, one group at a time. Each of them sees a different kind of pressure, and that pressure shapes the domain more than any diagram does.

Group meetings blur the picture. People soften their answers when peers sit nearby, and they get even more careful when a manager joins. Small private conversations work better.

Pick people who deal with live work every week, not people who only review summaries. A support lead who still reads the queue is better than a director who gets a monthly report. A salesperson who loses deals on the same objection is better than someone who only watches pipeline charts.

Talk to the person who still remembers last Tuesday. Real cases matter. They tell you where the system bends, where people bypass it, and where the current map is already wrong.

Keep engineering out of the first round. That sounds odd, but it helps. Engineers often jump straight to fixes or start defending the current design before the facts are clear. Bring them in later, after you collect the stories, so they can test what you heard against the code and infrastructure.

One question matters more than most: who actually feels the cost when the system gets awkward or fails? If the same pain shows up in product, support, sales, and ops, you are close to the real boundary.

What to ask product

Product usually knows where the product promise stops matching system reality. Start with trust, not features. Ask which user journey breaks trust first when something goes wrong: signup, onboarding, checkout, search, reporting, or account settings. The first moment users stop believing the product often points to the part of the architecture that needs a clearer boundary.

Then ask where roadmap promises keep hitting hard limits. A product manager might say, "We keep promising flexible pricing, but every exception needs engineering," or "We sell live dashboards, but some numbers only refresh a few times a day." That tells you more than a backlog ever will. It shows where the current model, ownership split, or data flow blocks the product from keeping its word.

Ask about the workarounds the team accepts before release. Product teams usually know which rough edges they quietly live with because fixing them would delay launch. Maybe they ship with a manual approval step, hide a setting for one customer segment, or avoid a feature on mobile because it behaves differently there. If a workaround survives more than a release or two, it usually points to a mismatch in the domain map.

Ask which data they still double check by hand. That question gets honest answers fast. If product people verify revenue totals, subscription status, permissions, usage counts, or customer history before a demo or launch, they do not trust the system to tell one clear story.

Do not ask product which service to rewrite. They rarely name the right technical fix. They are much better at naming broken promises, tolerated hacks, and numbers nobody fully trusts. That is the pressure your new map needs to reflect.

What to ask support

Support sees the mess that diagrams hide. Product talks about the flow it planned. Support talks about where real users get stuck, repeat steps, or give up.

Start with one blunt question: "Which ticket shows up every week, even when nothing changed?" Repeated tickets often point to a business rule users do not understand, or a system boundary leaking into the interface. If customers ask every week why an order says "paid" but still looks "pending," your map may be splitting one business state into two meanings.

Then ask which issue takes the longest to explain. Long explanations usually mean the model is awkward. Agents may need several messages to explain a cancellation window, a partial refund, or why someone can sign in but still cannot use the account. When support needs a script just to explain normal behavior, the architecture often reflects internal history instead of the business as customers experience it.

Ask where agents need admin help to close a case. Those handoffs matter. If support can spot the problem but cannot fix it without an account reset, a manual sync, or a permission change, the team boundary is probably in the wrong place.

Another good question is, "Which account states break your normal playbook?" Good support people answer fast. They remember the user whose trial expired after payment, the customer attached to the wrong company, or the canceled plan that still unlocks features. Those are not trivia. They show where the model bends or breaks.

Write down the exact words support uses. Their language is often clearer than the names in the code. It can stop you from redrawing the system around a version of the business that only exists on whiteboards.

What to ask sales

Sales is easy to underrate in architecture work. Product talks about intent and support talks about pain, but sales hears what customers think they are buying.

Start with the promise that closes deals most often. Then ask what happens after that promise lands. Does delivery need manual setup, a custom workflow, or extra approval steps to make it true? Sales language often sounds simple, while the system pays the bill later.

Ask which requests keep coming back in contracts, calls, and follow up emails. If the same exceptions appear again and again, treat them as domain signals rather than noise.

A few questions usually get to the point fast:

• Which promise helps you win, then creates work for the team later?
• What custom terms or feature requests keep showing up in deals?
• Where does the handoff to onboarding get confusing?
• Which objections sound like a product boundary problem?

Repeated asks matter more than flashy enterprise requests. Separate billing, custom approval paths, account level rules, department specific permissions, and special reporting can look like sales edge cases. In practice, they often expose a boundary the current map hides.

Pay extra attention to the handoff into onboarding. Ask sales what they explain on calls that the product still cannot explain by itself. If onboarding has to retell the story in a different way, the architecture probably reflects a fuzzy domain model.

Objections can be even more useful than wins. When buyers ask, "Can one customer account contain several independent teams?" or "Can access rules differ by region?" they may be describing a split your system has not made yet.

A small example makes this clear. One SaaS team thought it sold one workspace product. Sales interviews showed two very different deals: small teams wanted shared collaboration, while larger buyers wanted hard separation between departments. That difference changed onboarding, permissions, and billing, so the redraw started there.

What to ask ops

Ops usually knows where the business still runs on patches and habit. If you only study the code, you miss the work people do around the code to keep orders moving, reports sent, and customers updated.

Start with the work that lives outside the system. Ask which tasks people still track in spreadsheets, shared notes, or chat because the product does not support them well enough. Those side routines often reveal missing states, bad handoffs, or approval steps that never made it into the map.

Then ask about the point in the month that makes everyone tense. Month end is useful because weak parts stop hiding there. Maybe finance waits on one export, ops checks totals by hand, or someone stays late to reconcile data from two tools. If one shaky step can delay invoicing or reporting, your architecture should show that dependency clearly.

Data problems need their own questions. Ask where data arrives late, incomplete, or in the wrong format, and ask who fixes it. For example, orders may enter the system all day while the warehouse file lands at 4 p.m. with broken SKU names, so one person cleans the file before anything ships. That is not a minor annoyance. It is part of how the business works right now.

Last, ask what people do during incidents. Do they pause orders, switch to email, keep a manual queue, or re enter records later? The fallback path often tells you more than the happy path. If ops uses the backup process every few weeks, it belongs on the domain map.

Good discovery work does not chase theory. It uncovers the manual steps, timing risks, and repair work that keep the business alive.

A simple interview flow

Pick one real request that happened recently. Use something that moved through product, support, sales, and ops in the last few weeks. People remember the messy parts better when the work is still fresh.

Ask each team to tell that same story from start to finish on its own. Keep the interviews separate. Once everyone joins one call, they smooth over the rough spots too early, and those rough spots are exactly what you need.

As each person talks, write down three things:

• who touched the request
• what decision each person or team made
• where the work changed hands

That simple record usually tells you more than a polished diagram. You will spot hidden approvals, missing ownership, and steps that depend on tribal knowledge.

Pay close attention to names. Sales might call something an "account," support might call it a "workspace," and ops might track it as a tenant or deployment. When teams rename the same thing, the domain map is already starting to split.

Wait until you hear all four stories before you change the architecture diagram. Put the stories side by side and compare them. If the same confusion keeps showing up, you found a real pattern. If it appears once, you may have found a one off problem rather than a structural one.

Mistakes that distort the map

A bad domain map rarely starts with bad intent. It starts when a team tries to make the work tidy too early. One big workshop feels efficient, but it smooths over the rough parts. The loudest people shape the story and the messy details disappear.

Those details matter most. Support sees refunds, retries, manual overrides, duplicate charges, partial failures, and cases that slip past the happy path. Leave those out and the redraw will still fail when real work hits it.

Another common mistake is asking each team which features they want next. That gives you a wish list, not a map. Ask what slows them down every week, what they fix by hand, where data arrives late, and which steps create customer anger. Daily pain shows system boundaries better than feature ideas do.

Team names can mislead you too. Sales, support, and ops are reporting groups, not domains. A real domain can cut across several teams, or sit inside one narrow workflow that nobody fully owns. If you label boxes with department names, you usually redraw the org chart instead of the business.

Return flows are a common example. Support may handle the ticket, but billing moves money, ops checks stock, and product owns policy rules. Put the whole thing under support and the map hides the real pressure points.

Watch for a few warning signs:

• One manager answers for everyone.
• People describe approvals instead of business events.
• Exceptions get dismissed as "rare."
• The draft mirrors the current org chart.

Good discovery feels a little uncomfortable. People disagree. Cases conflict. Someone says, "We do that manually because the system cannot cope." That is usually when the map starts getting honest.

A simple example

A mid size SaaS team planned a redraw because "checkout" kept causing trouble. On the old diagram, checkout was one box between pricing and payment. It looked clean, but it hid several different jobs.

Product was not worried about cards or invoices first. It cared about trial conversion, upgrade timing, and what happened when a user changed plans in the middle of a billing cycle. Too many users started strong, then got stuck during upgrades.

Support saw a different pattern. Customers created duplicate accounts, lost access after a failed plan change, or paid on one login while using another. Those tickets looked like billing problems at first. Many of them actually started with account identity.

Sales pushed on the system in its own way. Bigger customers wanted custom billing dates, contract terms, and exceptions that did not fit the default monthly flow. The team kept calling those requests edge cases. After a while, those cases were driving a serious share of revenue.

Ops had no patience left for the old map. Invoice exports still needed manual fixes before finance could use them. Someone patched broken fields, corrected account matches, and reran jobs every month.

After separate interviews, the new map changed fast. "Checkout" was no longer one box. The team split it into billing, account identity, and entitlements.

That redraw fixed more than the diagram. Billing owned failed upgrades and invoice rules. Identity owned duplicate users and login conflicts. Entitlements owned who could access what after each plan change. The map finally matched the pressure the business felt every day.

Quick checks before you redraw

A redraw should make ownership clearer, not prettier. If the new map still leaves people asking who decides what, you have only moved boxes around.

Start with decision ownership. Each domain should own one clear decision that another team does not need to approve every time. If two domains can both change pricing rules, refund logic, or customer status, your boundaries are still fuzzy.

Then trace one real customer problem across the handoffs. Pick something messy, not a clean demo flow. A plan upgrade that breaks billing, a support refund that needs product input, or a sales promise that ops cannot fulfill will show you where the map bends under pressure.

Listen for repeated pain from different teams. When at least two groups describe the same bottleneck in different words, pay attention. If sales says custom deals take too long and support says exceptions keep piling up, they may both point to the same broken boundary.

A good sketch must explain the awkward cases too. Happy paths are easy to draw and almost useless on their own. If the map cannot show what happens when data is missing, a customer changes plans mid cycle, or an order needs manual review, it is not ready.

One last test is blunt and effective. Hand the sketch to a new hire and ask them to explain how one customer issue moves through the business. If they need a translator for team slang, hidden rules, or old system names, simplify it.

What to do next

Start with one workflow, not the whole system. Pick something that hurts often, like refund handling, lead handoff, or incident response. Then book four separate interviews this week with product, support, sales, and ops. Separate calls matter because people change their story when other teams sit in the room.

Ask each person to bring real material, not just memory. Notes help, but screenshots, recent tickets, chat snippets, and a lost deal summary give you a cleaner picture. If someone says, "This always breaks," ask them to show the last two cases.

Keep the first pass simple. Write the workflow in plain words, mark where each team enters and exits, note delays, workarounds, and missing data, and circle places where two teams describe the same step differently.

Do that before you open a diagram tool. Boxes and arrows look neat too early. Plain language exposes fuzzy thinking faster, and it is easier to argue with a sentence than with a polished chart.

Then test the draft against three real events: one lost deal, one support case, and one ops incident. If the map cannot explain all three, it is still too tidy. Good architecture work should reflect where money, time, and risk actually pile up.

Sometimes an outside review helps. Oleg Sotnikov at oleg.is does this kind of Fractional CTO work with startups and small companies, looking at product boundaries, infrastructure, and the day to day reality behind them. A fresh read can catch blind spots a team has started to treat as normal.