Business analysis
"We already know our customers." So did we.
The most common objection to business analysis is also the most reasonable one. Here is the part it gets right, the part it misses, and a promise our own product was making this week that no line of code was keeping.
Say you have run a trade for eleven years. You have quoted thousands of jobs, learned which customers go quiet after the estimate, and know exactly which week of January the phone stops ringing. Then someone opens a canvas and asks you to fill in a box labelled customer segment.
The objection writes itself: we already know our customers. And the honest answer is that you probably do — better than any workshop is going to teach you.
The part the objection gets right
Analysis frameworks earn the eye-roll when they treat domain knowledge as missing. It usually isn’t. The operator who has spent a decade in a market carries a model of that market far denser than anything a template will extract in an afternoon. A process that ignores this and starts from zero is not rigour; it’s ceremony, and it wastes the most expensive person in the room.
So if the pitch for analysis is “let us tell you who your customer is,” the objection should win. That is not what the analysis wing is for.
The part it misses
Knowing your customer and knowing what your product is currently telling that customer are two different facts. The first is stable — it’s earned, it lasts years. The second changes every time someone ships, and it decays without anyone lying.
Here is one from our own week.
Auslandscape is our landscaping platform. A homeowner finishes a design and posts the project to the lead board. The panel then tells them:
Posted — local landscapers are being notified. Check back soon.
We traced what that button does, on 30 July, in the current code. createLead writes a document to the leads collection and appends one line to the project’s activity log. That is the whole operation. No email is sent. No push is fired. No backend notification route is called. Landscapers discover the lead by opening the board and looking.
The product promises push. The product delivers pull. Those are different products from where the homeowner is sitting — one says help is coming, the other says check back yourself — and the sentence on screen picks the wrong one.
The detail that stayed with us is three lines further down the same function. Writing the activity entry, the code describes the identical action accurately: local landscapers can now respond. Two sentences, one event, written at different moments by people who each had it right in isolation. Nobody lied. Nobody ever read them side by side.
There is a second layer. On 26 July an internal audit found that no BIXSO app had ever sent a transactional email at all, and we shipped a standard and a mailer in response. It has ten notification types today — invitations, quotes submitted, decisions approved and declined, invoices, handover, messages, stalled projects, trial endings, and one for when a homeowner engages a specific landscaper. None of them is a lead was posted near you. The machinery that would make the sentence true now exists. This particular wire was never run.
Why customer knowledge could not have caught this
Run the objection against the failure honestly. We knew homeowners want responses quickly — true, and we still know it. We knew landscapers want local leads — also true. Both facts are correct, both are held by people who genuinely know this market, and neither one tells you whether line 87 of the panel is backed by anything.
That is not a gap in customer knowledge. It is a claim about your own system, and systems drift away from their descriptions quietly, in the ordinary course of shipping. Experience does not decay. Accuracy does.
This is the actual job of the A wing on our canvas, and why it sits between the model and the build rather than before both: not to discover the customer, but to keep checking that what you built still matches the customer you already understand.
The cheap version
We are not proposing a research programme. The version that would have caught this costs about a minute per screen. Take each user-facing promise and ask: which line makes this true?
If you can name the function, it is a feature. If you cannot name it in thirty seconds, it is an assumption wearing a feature’s clothes — and it belongs in the R box on the canvas, written down as a belief alongside the observation that would disprove it.
The strength of the question is that it fails loudly. “Local landscapers are being notified” survives any amount of experience, discussion and confidence. It does not survive someone asking which function sends the notification.
What we still don’t know
We cannot tell you whether this cost a homeowner anything. Auslandscape has not launched — the target is 1 August, sample profiles are labelled as samples, and real traffic is close to zero. We found it before customers did, which is the good outcome, but we found it through a manual audit rather than anything automatic. If it had shipped six months ago we would not have known.
And we have no monitoring for this class of problem. We can test that the button works; we have no automated way to check that the sentence next to the button is still true. That gap is open, we do not have a good answer to it, and we would take a better one from anyone who has solved it.
The BSC and the gate we run each box through are documented at bixso.ai/bsc.