The Surface Phase

I don't mean that as an accusation. I mean it as a description.

Every brief is shaped by who was in the room when it was written, what those people were willing to put in writing, and what they could agree on without stepping on something political. The brief reflects stakeholder consensus. Stakeholder consensus reflects who has power and what they can admit. Neither of those things reliably reflects the person who will actually use the product, in the actual conditions they'll use it in.

The brief is a best-available approximation of ground truth, filtered through three layers of organisational self-presentation.

After 200+ products, this is the thing I've learned to treat as a starting point rather than a source.

We concluded usability testing on a CPQ redesign a few weeks ago. B2B software, sales quoting platform, clear requirements from a well-structured brief.

Three sessions in, a rep shared her screen and had a spreadsheet open. Not the platform. A Google Sheet that six people on the team kept manually, updated by hand, running alongside the system that cost real money to build.

How long had it been there?

"Since about three months after we launched."

That sheet was doing three things the platform couldn't. Showing where quotes sat in three separate approval chains that had developed organically over time, none of which were visible in the interface. Letting reps collaborate on pricing before they committed. Flagging when something needed a human decision before it went to the customer.

None of this was in the brief. And it wasn't because someone hid it. It was because nobody asked. The spreadsheet had become so normal that it stopped being a workaround and started just being how work got done.

This is what your adoption data looks like before it becomes a bad number in a dashboard. Not error messages. Not support tickets. Six people maintaining a Google Sheet by hand, in parallel to the platform they're supposed to be using, because the platform doesn't tell them what they actually need to know.

We redesigned from the spreadsheet, instead of the original brief. The product we're building is substantially different from the one they asked for. It will also be one that gets used.

Every engagement where production adoption has fallen short, I can trace it to one or more of these being absent at the start.

The org dysfunction nobody documented. Every enterprise product sits inside a history. Teams that stopped coordinating after something went wrong eighteen months ago. Processes that calcified around a workaround that became unofficial policy. A product decision from three years ago that nobody revisits because the person who made it is now two levels up and the politics are complicated. None of this is in the brief. You have to go looking for it. The places where the answers are vague or the room goes quiet are where the actual work is.

The workarounds. The spreadsheet running alongside the platform. The Slack channel where people paste things out of the system before working on them. The sticky note that says "use this only if the checklist clears." These aren't failure signals. They're communication: users telling you, in the only language available to them, what the interface couldn't accommodate. Each workaround is specific. It tells you exactly what category of need the product failed to meet. Document them before you build. They're the real brief.

What success looks like in month four. Neither in the demo, nor in the pilot with the motivated early adopters. Month four, when the novelty is gone and the person using this is tired and under pressure and has three other things open. What does good look like then? What business metric moves? How would you know, specifically enough to test, that this worked? If you can't answer that at the start, you're optimising for demo conditions. Demo conditions are a fiction that nobody at 3am is living in.

When Jensen Huang says every SaaS company becomes a GaaS company, he's describing a world where the primary user of your software is an agent, not a person. The agent is executing workflows, making decisions, producing outputs, autonomously, continuously, at scale.

That doesn't make the Surface phase less important. It makes it catastrophic to skip.

If you build an agent for a workflow that was already designed for a user who doesn't exist, you've automated the wrong thing. You'll find out when it scales. When something that failed slowly in production now fails at the speed and volume of automation, the trust debt compounds faster than any human workaround can compensate for.

The spreadsheet a sales rep maintains by hand is recoverable. The agent that automates the process the spreadsheet was compensating for, without anyone surfacing why the spreadsheet existed in the first place, is not.

Surface first. Always. This matters more in an agentic world than it ever did before.

I've been running a set of questions at the start of every engagement for a few years. Twelve questions across the three areas above. The org dysfunction, the workarounds, the production success definition.

The places where the answers are vague, where people look at each other before answering, where someone says "that's a good question actually," that's where the real brief is.

If you want to run the full diagnostic on something you're building, just email me or send a DM. I'll send it across. No pitch behind it.

skipthesmalltalk@thirtytwonorth.com

A few things from this month that are worth sharing.

The CPQ engagement from above is active. We're building from the real brief now. When we have permission to share it fully, it'll be a case study worth reading.

We've just onboarded a new enterprise client. B2B platform, professional services. Early days, interesting problem. More as it develops.

On the GaaS point, we took Huang's argument seriously. We're running an internal hackathon at 32N with one specific goal: build integrated agentic solutions for how we actually work. No evaluate tools, no adding AI to existing workflows. We're building agents for how we scope engagements, run research, synthesise usability testing, manage content, handle client deliverables. If we're going to help enterprise teams navigate this transition, we should be doing it ourselves, under real conditions, and sharing what we learn.

Two weeks in. Some of it is working well. Some of it is humbling in the specific way that only things that don't work yet can be. Happy to share notes with anyone doing something similar.

MIT's GenAI Divide report says 95% of enterprise AI pilots fail to deliver measurable business value before being abandoned or paused.

The consensus diagnosis is infrastructure. Data pipelines. Governance. The skills gap.

MIT's own framing is more useful: "PoCs live inside a safe bubble. Data is carefully curated, integrations are few, and the work is handled by the most senior and motivated teams."

The most motivated teams. That is not who uses the product at 3am under accountability pressure with a spreadsheet open in the other tab.

The 12% who ship aren't running better models or spending more on governance frameworks. They're designing for real production conditions instead of curated pilot conditions. That's a Surface advantage, and every phase downstream gets better when Surface got it right.