Chapter 02 · Free sample
Route the problem before you solve it
Three problem types. Six steps. One closing loop.
Every incoming tax-technology challenge belongs first to one of three families. External change means the environment moved. Internal breakdown means the operation missed an outcome. Forward decision means the organization must choose without a failure forcing the timing. This first classification prevents the common mistake of applying a favorite framework to a problem it was not built to answer.
| Decision field | Working answer |
|---|---|
| External change | Start with the mandate radar and SCQA. Use a broader PESTLE scan when the change is structural rather than jurisdiction specific. |
| Internal breakdown | Start with the failed metric and KPI tree. Add the cost baseline when sponsorship depends on quantified impact. |
| Forward decision | Start with option generation, constraint screening, and an anchored scorecard. Sequence the answer on the roadmap. |
| Every path closes | Structure the evidence, test before scaling, communicate for the decision owner, and control the gain. |
This chapter is also the specification for the online problem router that ships with the book. The decision flow below is the intelligence behind both: when a tax technology practitioner arrives with a challenge, the flow routes them to the frameworks and chapters that solve it. In the book, the flow is a page you consult. In the router, the flow is an intake form you complete, and the router responds. The logic is identical by design; the two channels are generated from the same decision tree and should remain synchronized.
Reading the flow
Every incoming challenge sorts into one of three top branches. External change captures the moments where the world outside changed and the tax operation must respond: a new mandate lands, an audit notice arrives, a market shift disrupts a business model. Internal breakdown captures the moments where something inside the operation stopped working: a filing missed, a cost spike appeared, a control failed. Forward decision captures the moments where the operation is deciding what to do next, with no immediate breakdown driving urgency: a vendor renewal, a roadmap refresh, a scaling choice.
Each top branch routes to two specific analytical starts. External change routes to the mandate radar plus SCQA framing (for anticipated changes) or a PESTLE scan (for broader environmental shifts). Internal breakdown routes to a KPI tree for the specific failed metric, plus the cost baseline if the impact needs to be quantified for a sponsor. Forward decision routes to Porter's Five Forces in core chapter 16, with the expanded builder perspective in the Tax Technology Builder's Companion, chapter 2; ICE in core chapter 13 for prioritization; and the roadmap horizons in core chapter 17 for sequencing. Six starts, and every one anchors the practitioner in a specific chapter's method within minutes.
Every path ends at the same closing sequence. Structure the finding with chapter 4's MECE discipline. Test it with a chapter 15 pilot before scaling. Communicate the recommendation using chapter 3's SCQA and chapter 21's stakeholder map. Control the gain with chapter 22's DMAIC-style control step so the change persists. That closing sequence is what makes the method reliable rather than clever; it holds identically whether the entering problem was a mandate, a filing failure, or a scaling choice.
The six-step route every problem travels
Every framework in this book slots into one repeatable sequence. Consultants run it on every engagement because it prevents the two failure modes that kill most problem-solving: solving the wrong problem thoroughly and solving the right problem in a way nobody can follow. The six steps are define, structure, prioritize, analyze, synthesize, communicate.
The sequence is strict on purpose. Analysis before structure produces data without a home. Communication before synthesis produces findings without a recommendation. And skipping define, the most skipped step, produces the perfectly executed answer to a question nobody asked.
The process on a real problem
Running example, used because it hits most US tax technology teams eventually: a company discovers it has been triggering economic nexus in states where it neither registers nor collects. Define (chapter 3): the SCQA frame establishes that the question is not 'are we exposed' (yes, that is the complication) but 'how do we remediate at acceptable cost and stay compliant going forward.' Structure (chapter 4): break exposure MECE by state, by year, and by remediation path (voluntary disclosure, prospective registration, do nothing). Prioritize (chapter 7): 80/20 says a handful of states carry most of the liability; treat those first and batch the tail. Analyze (chapters 6 and 8): quantify exposure per state per path, including penalties, interest, and lookback windows. Synthesize: a recommendation, not a data dump. Voluntary disclosure in six states, prospective registration in nine, monitor the rest with a threshold-tracking control. Communicate (chapter 3): answer first, to the audience that funds it, tied to what they are measured on.
Six steps, five chapters of this book doing the work, one defensible outcome. That is the pattern for every problem in the checklists in Appendix A: the process routes you to the tools; the tools do not replace the process.
How to apply it
- Time-box define and structure to a day each. These steps produce clarity, not deliverables, and they expand to fill whatever time you give them. A day of honest framing beats a week of polishing the frame.
- Write the step you are on at the top of your working document. It sounds trivial. It is the cheapest known cure for analysis that drifts back into redefining the problem, and for meetings that jump to communicate while everyone is still on structure.
- Let the process be visibly incomplete. Telling a steering committee 'we are at step four of six; here is what the analysis is showing' buys more trust than pretending every update is a finished answer.