Act II: The Antechamber
Discovery Is A Posture
Week 1 of discovery. The finance lead writes, in an eight-minute pre-survey, that the new system must preserve the exact tax compliance fields he added in 2022. The e-commerce director, who defined success in last Thursday’s meeting as “a faster, simpler checkout,” has not been told.
Week 6 of the build. The customer service lead mentions, in passing on an unrelated call, that the Friday afternoon block in her calendar called QB stuff is four hours of manually re-entering refunds into QuickBooks. Nobody had thought to ask. She had not thought to volunteer.
Week 14. Someone in the warehouse asks, on a Tuesday morning, what the migration is going to do about the morning pick sheet that gets generated from a flat-file FTP. The flat-file FTP is on a server that has been “scheduled for deprecation” for three years.
These are not three failures of discovery. They are three successes. They are the same success, surfacing three different times. They are what good discovery looks like—continuously, across the arc of the project, not in one heroic burst at the beginning.
This is the chapter where we tell you that discovery is a posture, not a phase.
The temptation, when you read a guide to enterprise replatforms, is to treat discovery as a project phase—the one with a deliverable called the solution proposal, the one that ends before the build begins. We do this too. We schedule it. We bill for it. We hand over the document. There is a kickoff, and the kickoff has a dinner, and somebody, eventually, says “discovery is complete” in a status email.
The status email is lying.
What is true is that the workshop is complete. What is true is that the first pass at the solution is complete. What is true is that the team now has, in their hands, the best picture of the project they will have for about three weeks, after which the picture will need to be updated, because something will have surfaced.
Discovery is not a deliverable. Discovery is a stance the team adopts and keeps adopting. The workshop is where you begin practicing it. The next forty weeks are where you actually do it.
Eisenhower had a line about this. Plans are useless; planning is everything. Eisenhower was talking about an army. We are talking about a Shopify migration. Both involve large numbers of people coordinating their behavior toward an outcome they cannot fully predict, and in both cases the value of the plan is not the plan. The value is the act of planning—and, more importantly, the willingness to keep planning. The artifact you walk out of the workshop with is, in some real sense, a souvenir. The posture is the asset.
There are three reasons surfacings keep happening, and they are worth naming, because they are all structural. They are not the result of a bad workshop. They are not avoidable through harder preparation. They are baked into the shape of any enterprise migration, and a team that does not expect them will be repeatedly, expensively surprised.
The first is that the organization itself does not know everything it knows. The Friday-afternoon QuickBooks block, the morning pick sheet from the orphaned FTP, the checkout field added in 2022 because of a Mississippi audit—these are not secrets the organization is hiding. These are facts the organization has adapted around. They have become invisible to the people doing them, the way the hum of a fluorescent light becomes inaudible by week three. The workshop surfaces some of them. The build surfaces more. The cutover, predictably, surfaces what is left. The QA team, three days before go-live, surfaces one nobody believed was possible.
The second is that the future state is itself a moving target. The platform you are migrating to is not stable; it ships new capabilities quarterly, and some of those capabilities will, in week 19 of your build, make a decision you locked in week 4 look slightly silly. You did not, in the workshop, know that Shopify was about to ship the new Markets capability you actually needed. You could not have. The posture is what lets you respond to the new capability as an opportunity rather than as a failure of planning.
The third is that the organization itself is moving. The director of operations gets a new boss in week 11. The brand acquires a small B2B-only company in week 17 and the migration now needs to think about wholesale provisioning. Legal, in week 22, hands you a new compliance requirement that came down from an outside auditor. None of these were in the workshop. All of them are real. None of them are reasons to scope-creep the project. All of them are reasons to maintain a working memory of the project’s actual context, which is changing whether or not the project plan acknowledges it.
The requirement you inherit is not the requirement you have. That was an earlier catechism. Here is its sequel: the requirement you have today is not the requirement you’ll have in six weeks. The point of the posture is to make the team comfortable saying so, out loud, when they notice.
What does the posture look like in practice? It looks like a small number of recurring habits, each of which is unremarkable in isolation and load-bearing in aggregate.
It looks like, at the end of every week, somebody on the project asking the question what did we learn this week that we didn’t know at kickoff?—and then waiting through the awkward pause until somebody answers honestly. It looks like the answer being recorded somewhere a future version of the team can find it. It looks like the project’s working assumptions getting updated when the answer warrants it, in writing, with the previous version preserved so that nobody has to pretend they always thought the new way.
It looks like the integration spec being amended in week 9, when somebody finds out the ERP also feeds a second downstream system nobody mentioned. It looks like the architecture diagram being actually re-drawn, not just annotated—re-drawn so that the team that joins in week 14 can read it without needing a tour guide. It looks like the data model being revisited in week 11, when the wholesale-arm acquisition lands. It looks like the steering committee being told, with a straight face, we discovered something this week that means we want to revisit a decision from week 3. It looks like the steering committee receiving that news with curiosity rather than alarm, because the team has been training them, all along, to expect it.
It also looks like the pre-mortem getting rerun. Not once, at the end of the workshop, but every couple of months. It is six weeks from go-live. The launch has failed. What did we miss? The answers in week 4 are different from the answers in week 22. Both are useful. The team that runs the pre-mortem in week 22 and finds nothing new is either lying or asleep.
None of this is exotic. None of this requires a methodology. It requires, mostly, the willingness to keep saying out loud that the project is still being figured out—and the discipline to keep doing the small administrative work that makes the figuring-out legible to people who join later.
There is an agency archetype that does the opposite. It is worth describing, because you will meet it.
This agency nods sagely when a new finding emerges in week 9 and says yes, we’d already accounted for that, in a tone calibrated to communicate competence and to discourage further questions. This agency exists, in this moment, to make the brand feel like the agency knew. It is, in this moment, doing the brand a small expensive disservice. The disservice is that the finding does not get integrated into the project plan. The disservice is that the team learns, by example, that surfacing new findings is not the kind of thing this project does—which means the next finding, the one in week 13, will not get surfaced at all. The next one after that will surface in week 22, when surfacing it requires breaking something open that should have been adjusted gently six months earlier.
The agency that says, instead, we hadn’t accounted for this; here is how it changes our thinking—that agency is more useful to you in week 9 than the agency that pretends in weeks 9 through 22 and discovers, in week 23, that pretending no longer works.
You will notice the difference in week 9. We are telling you to notice now, before week 9, so you know what you are looking at when you see it.
Owen Caldwell, Greycott’s Head of E-Commerce, ran his discovery workshop on a Tuesday in early November. He had sent the pre-survey. He had run the synthesis. He had stood at the wall with the warehouse lead and the finance lead and the customer service lead and asked, repeatedly, why is this here. The workshop went, by Owen’s account, well. By the agency’s account, it had gone well too.
The agency took the synthesis home, wrote the solution proposal, walked Greycott through it on a Wednesday afternoon, and emailed everyone a PDF the following Monday. Owen forwarded the PDF to his CFO with a note that said Looking good. We’re ready to start building.
Owen, in writing this email, believed two things. He believed the discovery phase was complete. He believed that the next phase was the build. Owen will, over the course of this journey, discover that both beliefs were wrong in the same way.
In week 4 of the build, the warehouse lead will call Owen to ask about the morning pick sheet from the orphaned FTP. (Nobody asked her about the FTP in the workshop, because the FTP had not occurred to anyone as a thing to ask about. It is the kind of detail the organization has adapted around.) In week 9, the finance lead will table a memo about a new state tax-compliance requirement that has come down since the workshop. In week 14, Shopify will announce a Markets capability that resolves, for free, a build the agency had estimated at twenty-six developer-days.
None of these are catastrophes. Each of them, if Owen has been in the posture, is a moderately satisfying conversation followed by a small update to a document. Each of them, if Owen has not been in the posture, becomes a small crisis followed by an awkward steering-committee email beginning we have run into a complication.
We will visit Owen again later, in both registers. The thing the chapter wants you to notice about Owen now is that the workshop ending is not, for Owen, the end of discovery. It is the moment Owen has the option of closing his posture or keeping it open. He has not yet decided. The Monday email could go either way.
We are talking to you now. Specifically.
If you are about to schedule your discovery workshop, run the runbook. Send the pre-survey first. The runbook is not optional, and it is also not enough.
If you are in week 6 of your build and somebody on your team has just surfaced a load-bearing manual process nobody mentioned in the workshop, do not punish them. Thank them. The posture is fragile and you are the person, in this moment, responsible for keeping it open. The team is watching how you respond. So is the team member who has not yet surfaced the thing they are sitting on.
If you are in week 14 and the platform has just shipped a capability that resolves twenty-six days of work you had scoped, take the win. Then ask, in the next standup, whether anyone has been holding back a finding because they thought the project was too far along to absorb it. Two of them, statistically, have.
If you are in week 22 and the steering committee is about to be told that something has changed, draft the note carefully. Lead with the finding, not the apology. We have learned something that affects the project. Here is how we are going to handle it. The steering committee will absorb the news according to how you have trained it to absorb news. If you have been quietly slipping concerning items into status reports as risks without ever surfacing one as a finding, you are about to have a harder week than you need to.
Starting well is most of the work. Most of the rest of the work is starting well again, every week, on a smaller scale, on whatever has surfaced since the last one. The teams that do this are the teams whose migrations land. The teams that close discovery on the Monday after the workshop are the teams whose migrations land with a small surplus of unresolved items, which then form the punch list for the first six months after go-live.
You are not, we hope, in the business of accumulating a punch list.
You are in the business of building a posture.