For most of my career, every engagement opened with the same three-word ritual: buy, partner, or build. My job was (usually) about the long-term and competitive advantages of the third one, as it was nearly always written off as too long and too expensive from the very start. Build was the slow, expensive, risky path you eliminated first or put most of your bet on. But that has changed. I sat down with Craig Unsworth, a Portfolio Chief Product Officer and the author of Chiefly Product, to talk about why build is back on the table and what that does to teams, judgment, and the people who do the work. — John

John: For years, putting “build” next to “buy” and “partner” as an equal option was almost irresponsible. You needed an extraordinary case to justify it. 

AI changed the math. The time and cost to get from an idea to a working concept has collapsed, putting build back on the table as a genuine choice. We took an education company, Modiv EDU, from market opportunity to a launched platform in under a year — a small team — soup to nuts: business case, board investment support, demand validation, revenue model, design and brand. That used to be a fantasy timeline. 

You work across far more private equity than I do. What are you seeing on the ground?

Craig: The same shift, and it’s dramatic. I spent a decade known for moonshots — delivering three to four years of work in twelve to eighteen months. Today I’d scope much of that same work as three- to six-month builds, end to end. That changes everything: your risk appetite and whether you fix something or throw it out and start again. And the shape of the team is changing too. More and more, it’s one person orchestrating AI capabilities, specialists, and workflows — rerouting processes across the business and running several projects at once. That’s the individual transformer, and the rise of that role is the most exciting change I’ve seen.

John: Here’s the thing, though. The headline is speed, but speed isn’t the real change. When building gets fast and cheap, the hard question becomes what to build, and for whom. I’ve actually started wanting to test less but far more intentionally. Not 20 tiny A/B/C/D experiments, but big, chunky ones I’m willing to stand behind. Ten years ago that would have been reckless. Now the constraint is judgment, not throughput.

Craig: I’d put it almost the same way, though I don’t mean run fewer checks. I mean spend less time designing the perfect test and more time running rapid experiments with fast feedback loops. Rigid, staged testing — run the versions, pick a hypothesis, test again to be sure — nobody has the bandwidth for that anymore. Iterating as you go, failing small and clawing back quickly: that’s the discipline now. And it’s why I care so much about how we train people. I’d love to see learning move toward short, intense, experiment-led programs, because you don’t make your mistakes in theory. You only make them in practice.

John: That’s the part that worries me. Judgment has become the imperative skill, and yet a lot of the AI-tied layoffs are hitting exactly the people who tend to carry it — middle managers. Some of that coordination work genuinely does go away with AI, and I’m not arguing to protect layers for their own sake. The worry is narrower: a lot of judgment happened to live in that layer, and that’s the part we can’t afford to lose. I grew up in an apprenticeship model, and I think we’re removing the rungs younger people used to climb. Meanwhile, the senior person who’s left is in constant review, and if work slips through, the whole thing jams. Doing that alone is overwhelming. 

It’s why we never staff a one-person engagement — we pair a senior lead with a second senior thinker to collaborate and add an additional layer of quality review of the work and extend it, and we price by capability, not hours, so the pairing of two Sightglass people is never a line item to negotiate away. We worked that way with Jack in the Box: my co-founder, Matthew, and one of our principals, Jessi, partnered directly with their CTO on menu-data modernization. The outside view and the inside context have to sit side by side.

Craig:  A lot of teams have simply deleted the middle layer — the governance, the slower processes. Yes, that gets you from A to B faster. But it isn’t free. If you build faster, you also reach your failure faster, if you’re going to fail. So you have to build the resilience and the recovery model back in — something that still holds the guardrails and answers, “What does good look like, and who’s the arbiter?” 

The real danger is cutting under the banner of “AI efficiency” to mask legacy debt, only to find you can’t undo it. Big tech recovers from that. In the mid-market, cutting a function of four down to two can mean losing the knowledge entirely.

John: One of my favorite pieces you’ve written is “The Return of the Rebuild,” and what I like is that you argue for build to avoid getting trapped in legacy constraints. Can you elaborate on this idea?

Craig: It comes down to refusing to renegotiate decisions from 15 years ago for the entire life of a project. We’ve all watched two market leaders sit and stare at each other, both hesitant to pay down their tech debt and then two people in a garage ship something new. They didn’t build version 1.7 of what exists. They asked, “If we were building this today, what would we build, and what would we say no to?” 

My projects have a popularity curve: people love it early, then it dips hard when we start saying no, and then confidence comes back because every yes you deliver was sponsored by the 75 nos behind it. It’s 2026. No customer wants software built the way it was in 1992. And with moats shrinking from a few years to a few months, complacency isn’t an option.

John: The version of “build” I enjoy most is re-architecting the product suite of a company that’s made multiple acquisitions and reassembling it through product, brand and design systems, workflows, navigation, and support, all behind the now deeper use cases. The technology is rarely the hard part; the head change is. But when the actions connect through the now-shared data and finally behave the way you’d expect, one plus one starts to equal three. AI is making these product integrations faster and cheaper while also making judgment and experience decisions more impactful than ever before.

Which is really the point: the efficiency AI gives back is real, and the open question is what you do with it. My hope is that companies point it at growth rather than only at cuts. A team of six doing the work of ten, not a team of ten cut to six.

Craig: That’s the shift I’m seeing in the best transformations. Thirty people becoming 20 doesn’t mean 10 walk out the door. Two or three move upstream to invent something new, a few finally fix the basics that have been dragging for years, and you let some natural attrition do the rest. There’s a headcount story, sure — but mostly it’s about doing exponentially more with what you already had. 

The reason we’re having this conversation instead of plowing a field is that we had an industrial revolution. This is the next one, and I hope it ends up being about balance, throughput, and more predictable outputs because that’s how we all actually want to run a company.

John: The thing I keep coming back to isn’t the speed; it’s the shift sitting underneath it. For most of my career, the hard part was building the thing. Now the hard part is deciding what’s worth building and relying on people with the judgment to make that call. 

So I find myself wondering whether the next few years belong less to whoever moves fastest, and more to whoever still knows how to ask a good question and is willing to bring someone else along while they answer it.