AI’s effect on middle management
A small study of how consultancies are using AI concluded that both juniors and execs are getting the most value from it — at the expense of middle managers, who now have to verify that the output is good. Subsidiarity is a key design feature of effective complex adaptive systems. Your org is one of them: your managers hold local context. Think twice before overloading (or worse, firing) them. (HBR gift link)

Gen AI and Taxonomies
Large language models work best given the right context — including the ability for agents to find the stuff they need. “Old school” taxonomies help a lot. And conversely, LLMs can help us create better taxonomies. Heather Hedden covering what feels like an essential — and for the most part, underappreciated — idea: that smart systems must be propped up by a lot of structure.

How AI is changing marketing
McKinsey claims over half of consumers are using AI to make purchasing decisions. But that’s only part of it: AI is fundamentally changing how marketing is done. But it won’t happen with ‘bolt on’ solutions. Instead, reinventing marketing calls for a complete redesign of how organizations market their wares. I’m biased, but several of the “new” roles described in here read like “information architect” to me.

Traction Heroes Ep. 39: Pace Layers
AI makes prototyping easy. But moving from prototype to production requires lots of architecture. In the latest episode of our podcast, Harry Max and I nerd out on one of the models that has most influenced my work: pace layers. If you think design is about making screens frictionless, easier to use, or (for Pete’s sake!) more attractive, you’re focused on the wrong layer.

CTO Report on cognitive debt
This feels ai-written, but I still found it useful: an informal report from a gathering of CTOs on what they’re seeing on the field. TL;DR: the AI free ride (i.e., unlimited budgets) is over; it’s time to invest in architecture. If your leadership is still suggesting replacing complex workflows with AI, send them this one.

Building Reliable Agentic AI Systems
An in-depth case study on how Bayer built a reliable AI research assistant for their (highly regulated) business. They turned decades of latent data in unstructured PDFs into highly structured context, implemented specialized agents to use that data, and created mechanisms to anticipate and correct the inevitable failures. Bottom line: it’s not enough to give LLMs access to your data; reliability requires architecture.

Big-time self-disruption
Tide is P&G’s biggest brand. Every thirty years or so, they risk it by introducing a new form factor (e.g., pods.) This cycle is about to start again with new detergent “tiles” — a bold risk. How far is your organization willing to go to disrupt itself? You likely don’t have a $2b annual R&D budget, like P&G does. They also have structures in place (including decades-long brand equity) that allow them to make such bets. The challenge for the rest of us? AI makes innovative moonshots more feasible, but bold bets without support structures and solid market signals aren’t reinventions, they’re expensive gambles.

The Birth of the Flywheel
If you and I have spoken at length, there’s a good chance we ended up discussing the Walt Disney Company. I’m a big fan, and have written about what we can learn from them when designing complex information environments and beyond. But this four-plus hour episode of the Acquired podcast goes much deeper, diving into the company’s history up to the early 1980s. The focus? Disney’s (accidental?) discovery of the synergistic business model they exemplify. It’s a history lesson on the successful merging of art, commerce, and technology. Takeaways: 1) build a diversified yet cohesive business model that creates self-reinforcing loops and 2) honor the Walts (i.e., creative geniuses) in your team willing to bet the farm — so long as you have Roys (financial geniuses) keeping the company alive. (The business model, you can design for. The geniuses… not so much.)

See you next week!

— Jorge

In systems thinking, this principle was best articulated by John Gall:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

I’ve long promoted Gall’s law to students and clients. It’s been hard going. We want to see products and services in their full glory ASAP. But you can only throw so much cash and person-hours at a problem. Ergo, we got the time-tested idea of a minimum viable product. (It’s no coincidence that orgs with more resources violate Gall’s law more often than scrappy startups.)

But the value of an MVP isn’t just that it allows you to get something that works quickly and cheaply. Instead, the value is that that first try isn’t overspecified to theoretical conditions. It’s only a draft meant to kick off an evolutionary process that leads to a system that meets real-world customer needs.

AI removes these constraints. An afternoon with Claude can yield a comprehensive spec for a very complex system. Further sessions can architect the system and build an initial release that includes bells, whistles, timpani, harps, violas, and all the other instruments in the orchestra. All this, at a fraction of the cost and time it would’ve taken in the past.

That’s amazing. It means we can now design and build much larger systems, faster. This opens new possibilities. Not just one new feature, a new product. Not just a new product, a suite. Not just a suite, a platform. The possibilities seem endless.

But in removing architecture and development constraints, we’re also removing the need to focus on what matters most and the discipline to run it by the market. All that upfront complexity doesn’t necessarily address real-world needs. Instead, it reflects a singular top-down vision that may or may not provide value to others.

Whereas MVPs in the “before times” called for minimal investment before validation, LLMs promise a much more realized vision from the first go. But there’s a significant difference between a sexy concept car and a vehicle customers will take grocery shopping. AI-augmented workflows will give you the former, but not the latter.

Here’s an example. Two years ago, I started building a product called SiteRanger, an AI-powered agent to help small teams manage large websites. This was before Claude Code or any of the current coding agents. Still, I got surprisingly far by using Claude to augment my basic PHP skills.

Together, we built a functional MVP that implemented what I considered to be the core functionality. The problem: my “core” was in fact an open-ended platform. Rather than solve a particular customer problem, it was designed to solve classes of problems.

By the time I got alpha users on board, the system was wildly over-architected. Worse, I learned new agentic systems could provide ~80% of its value. When I looked to pivot, I realized I’d have to move in a completely different direction, one with entrenched incumbents. It wasn’t worth it.

It wasn’t all a loss. This experiment taught me a lot about developing AI-powered software products using AI. But the most important lesson I learned is that AI makes it VERY easy for individuals and small teams to land in the same trap as resource-rich orgs: no constraints.

Which isn’t to say you shouldn’t use AI. To the contrary, I’m all for accelerating MVP design and development. But the word “viable” is fungible, especially when you have robot engineers. You want to expose the product to the discipline of the market. That means releasing something embarrassingly simple at first. And that requires discipline and constraint — the two things most scarce when working with LLMs.

My friend Karl Fast pointed me to a wonderful scene in the movie A RIVER RUNS THROUGH IT. The main character, a child, brings an essay to his dad, a strict preacher, for evaluation. The dad’s only reply: “Half as long.” The child does, and returns with the edit. After scribbling with a red pencil, the preacher looks at him and says: “Again, half as long.”

Step away from the console and ask yourself: What would I cut if there were no AI building it? Cut, cut, cut. Then imagine Tom Skerritt staring at you over his schoolmaster glasses and saying drily, “Again, half as long.”

A frontier without an ecosystem is not stable
Satya Nadella offers a refreshingly adult perspective on the relationship between AI and human capital. The two are interdependent; AI isn’t a replacement for people. My take: in a world where AI labs want to lock you into intelligence-on-tap (at an initially subsidized cost), architecting context around your data and IP becomes your moat.

Doom Trolling
Cal Newport on frontier labs’ incessant fearmongering as a way to gain attention or regulatory capture. Or perhaps they believe their rhetoric, which would put them in an ethical bind. Anthropic’s fearmongering has now led (perhaps wittingly) to the U.S. government slapping export restrictions on them. This is a risk if you build solutions around these proprietary systems. (NY Times gift link)

The Heart of LLMs
Melanie Mitchell on the intrinsic limitations of LLMs. Experts have differing opinions on these systems’ capabilities and constraints. I’m with Yann LeCun: “A system trained on language alone will never approximate human intelligence, even if trained from now until the heat death of the universe.” That doesn’t mean they’re not useful, but the degree of intelligence they demonstrate at performing day-to-day tasks is almost entirely dependent on how you architect their context.

What it feels like to work with Mythos
Last Friday, a client and I experimented with Anthropic’s Fable. I’m glad we did: a few hours later, the U.S. government slapped export restrictions, forcing Anthropic to pull the model for everyone. It’s still unavailable, but if you want a sense of how Fable/Mythos differs from other models, check out this post by Ethan Mollick. My take: these advanced frontier models are very expensive and energy-intensive for most day-to-day tasks. But for a certain range of problems (e.g., research, which is what my client and I did with it,) they’re unparalleled. The risk: you lose visibility and agency in the decision-making process.

See you next week!

— Jorge

In the third of our Open-Ended Sessions, we discussed how AI is changing how product and design work are done. In particular, we’re tracking the shift from feature- and screen-level work to more strategic and human-centered system design.

Lots of orgs are choosing to deploy AI as a means to do more of the same, only faster and cheaper. But AI can also be used to unlock new possibilities by augmenting (rather than replacing) humans.

As Greg put it,

The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum.

Ultimately, the key question isn’t what the technology is capable of, but what it’s for.

Links

Books and posts mentioned in the conversation:

• Magnifica Humanitas by Pope Leo XIV

• I think Anthropic and OpenAI have found product-market fit by Simon Willison

• The Cost of Being Busy by Craig Hepburn

• The Feature is Dead. The Job Remains. by Greg Petroff

• This Moment We’re In, Ep. 3 (Greg’s conversation with Cindy Chastain)

Transcript

(AI generated — likely contains errors.)

Jorge: All right, hey Greg.

Greg: Hi Jorge, how are you?

Jorge: I am doing all right.

Greg: Yeah.

Jorge: It is interesting times.

Greg: Oh my gosh, yeah. You know, I think when we were talking about perhaps hosting one of our sessions here, it was really about the zeitgeist, like what’s happening this moment. And there are these peaks where all of a sudden there’s some kind of thread that shows up that just begs to be probed. So thanks for encouraging me and us to have these conversations. And for those who are joining us, welcome to number three of our Unfinishe sessions, where Jorge and I just talk about stuff that we think is interesting that’s going on. And we hope you find it valuable as well.

Jorge: Yeah. And it might be worth recapping beyond the open-ended conversations. This is not just something that we’re doing because we want to talk about things that interest us. In some ways, it feels like the transformations that we’re seeing are, sounds kind of heavy-handed to say it, but they’re existential. They kind of are. And these conversations I see as an opportunity to name the things we’re seeing. You have your note taker just joined when he’s trying to join. You see, it is existential.

Greg: That’s right. There we go. Goodbye.

Jorge: It might be worth unpacking what that means, but we have not pre-scheduled these, to your point. We’re kind of calling these conversations when we have sensed a shift in the zeitgeist. And this is the third one we’ve had so far. And I’m going to try to sketch out the conditions that precipitated this one. And then we’re going to circle back to a post that you shared, which I see as kind of like a way to deal more skillfully, for organizations to deal more skillfully with the situation that they find themselves in now. But there are several factors at play here. One is the big shift toward the end of last year. I think we saw a big shift in how people in general are thinking about AI. Agentic software development tools like Claude Code started proving their mettle in the organization, right?

Greg: Yeah.

Jorge: And Simon Wilson recently had a blog post where he said that Anthropic and OpenAI have found product-market fit. And he was referring specifically to these tools, right? So there’s been this shift from a modality that is more focused toward software development. And then we have things like Claude Code that build on that agentic way of working with these systems. So that was a big shift toward the tail end of last year. And then I would say that around the end of the first quarter of the year, we started paying the piper, literally. Organizations have started realizing that that kind of usage can get very expensive, right? And we’ve started to see some organizations start to pull back, capping their people’s budget for using these tools.

Greg: I would just build. I’ve been working as a fractional for a couple of different companies, fractional design leader, for those who haven’t heard that term before, over the last year. And to watch how product organizations have started to use these tools, and then the uptake in them, and then the capabilities that they unlock, and then the speed that teams can work at, and more importantly that you can do more, it’s been really remarkable to watch. And at the same time, it’s causing all kinds of churn because teams are struggling with who does what, how, when, and they’re hitting some of these issues too around utilization and use of the tools and the cost of using the tools, and not just the financial cost of using the tools, which can be significant when teams burn through their tokens, but the cognitive costs of using these tools, because you can build incredibly dense, rich, powerful documents now, but then your peers have to have time to consume them. And one of the things I’m noticing is that many of us are collaborating with our AIs more than we are collaborating with each other. And so there are all these kinds of things that we’re learning in the process of using these tools. And I also think there was some hyperbole around what was going to happen and how this might change things and the number of people, etc., that I think is starting to not show up. I think there are some things that we can think about that are different. So in this moment, yeah, we saw toward—

Jorge: Beginning of the year, organizations were starting to boast of how many tokens they were using, and they had leaderboards for this stuff.

Greg: Yeah.

Jorge: Which is another factor here that I think the emphasis was clearly on adoption as opposed to value creation. And one of the things that has shifted is, well, first they’ve stopped doing that because I think they realized, like, hey, this is really expensive. But also, that’s no way to measure progress, right? What you want to do is you want to be actually creating value. You don’t want to be boasting of how much you’re using the tools, right? So it feels like we’re kind of speed-running the process of maturing into how—

Greg: These tools can serve human needs. Yeah, there’s a whole set of new problems that are showing up inside product organizations around utilization. Are you using the right model? Are you leaving your context window open too long and therefore every time you ask for something you’re burning through credits like mad? Did you budget appropriately for the amount of credits that your team is using? What does finance think about all of that, right? I think there’s a whole bunch of things that are popping up right now. And some of that showed up in some recent announcements with Microsoft deciding to turn Claude off inside of their environment. There’s been conversation about bringing their own code development tools and their own models to bear, so maybe that has part of it. But I also, from what I understand, they were spending a lot of money. And my own experience in watching the team that I’ve been helping, the startup that I’m working with, is we run out of credits on a regular basis, or tokens on a regular basis. And then we have to go and ask for more. And there’s no real governance or process in place for a small company where they’re kind of making it up as they go and trying to understand what it means. They want to go fast, and so they’re willing to spend the money, but they have finite resources. So they can’t spend as much as they maybe think they should, or as the team wants to spend potentially. And there are all sorts of stories around teams that have burned giant holes in the budget of their organization by doing things which may not have been valuable, right? And it goes back to your point around this leaderboard thing. And I think one of the things that there’s a really great post by Hepburn about the cost of being busy that I think is really interesting to me. It was really about the teams that give the tools so that AI can be adopted throughout the organization and people sort of adopt them at their own speed are not really getting all that much productivity gain. They’re getting richer content perhaps, but they’re not institutionalizing the work in a way that takes the work that’s repetitive or less of priority and maybe building agents around that so that you can unleash your people towards new things. And I think there’s another aspect of this, which you and I started, I think this is one of the reasons why I wanted to talk this week, was Pope Leo’s encyclical came out, and it kind of fits a notion that we’ve been talking about for Unfinishe, our practice, which is we want to help organizations discover how they can, you know, the possibilities of unleashing their talent towards new efforts versus a productivity gain where you’re laying people off because you don’t need them anymore, right? I think it’s a very different mental model. And I think that there’s something about this conversation that needs to come up around the humans in the system and the value that these tools create for us, but also the value of work, etc., that I think is a notional, the conversation’s happening now and that’s good. And I think that document was a really important document to come out. And there’s been a lot of conversation around it. I know you have a take on it, but some people will leave it at that and hear what you think.

Jorge: Yeah, and I’m glad you brought that up. And even though this is turning into a kind of long preamble, I also want to bring to the table the conversation that you had with Cindy Chastain on her podcast.

Greg: Yeah.

Jorge: Because that conversation also circled around some of these issues. And I’m going to try to name it, just hearing you talk about it. I’m going to try to name the connecting thread for all of these things that we’re observing. And the thread is the question: but what is it for? It’s like, what are we doing with this, right? What’s the point? The conversation with Cindy, one way to summarize it might be something like: for design and product teams, there are two possible things that you can do with this. You can approach it as a way to do the things you were doing before more efficiently, faster. I don’t know if more cheaply, as is becoming evident, but do, let’s say, more with fewer people, right? Or another possible approach you could take is you could take this as an opportunity to do more with the people that you have, or maybe even with more people in your team, right? Just empower them to explore possibilities that were previously unattainable because of the natural constraints of a team of humans and their limited cognitive abilities and attention. And I wanted to bring that up because, A, I think that we, well, I’d love to hear your take, but I think that we’re both in the second camp. It’s like, hey, let’s see how we can augment people to do more. Because one of the things that motivates us in our shared practice is possibilities, like opening a broader space of possibilities, right?

Greg: Yes, I think with possibilities, intention, like what future do we want to have and how do we help teams and organizations fulfill that in an intentional way? And I love that you brought that up because I think the conversation that Cindy and I had was really about two stories. I’ve been doing this fractional work, and over the last year I’ve worked with two different companies, and sort of not at the same time, too. So one was sort of last year to the end of last year, and the second one is I’m currently engaged with and I started with in January when all these tools started to mature. And there are sort of two conversations. The first one was sort of dabbling with AI, learning how to use the tools, some experiments with vibe coding, etc. The second one was the design team and the product team not only using those tools, but exploring whole new territories that we just didn’t have time for in the past to do. So we were imagining a new product capability, a new product category for a company, not a pivot, but an expansion of this particular organization’s remit that they want to serve. They had a really good idea of a set of problems they wanted to solve. And we just did things that were just hard to argue for in the normal timeframe that software development gets built. And we were able to do them. So we did a bunch of work on information architecture. And one of the things that we did is we looked at competitive tools that were out there, other people trying to solve the problem in similar ways, and we did really deep analysis of how they structured their experiences so we could try to understand why they were doing it. And that helped inform a better architecture for us. We did a bunch of work looking at agentic systems and emerging conversations around how to build MCP apps. And that was exploratory. Frankly, I think it’s exploratory for everyone who’s working in that area. And so we were able to help use the process of making to define the product requirements. And in some ways, we were leading product development in that conversation because we were really trying to understand meaningful outcomes. And we came up with this thing we called the job brief, and it worked for us very well. So I think the opportunity right now is to build much better products. The concept of an MVP to me is sort of like something that needs to be reexamined because most MVPs were always insufficiently great because they were constrained by time and engineering resources. And now, where engineering resources are less constrained, why do we put product into the market that isn’t foundationally awesome? And so we can do that. And I think there’s an opportunity to really ask the organization to rethink how it takes the time of their customers and fulfills their needs and their goals. And we can be much more clear and more polished and build things which on launch make people feel seen, the users of them feel seen in a way that we couldn’t do before. And so I think that to me is an inkling of what these tools should be doing. And that’s just a product development example. But I think you could do this for organizational change. And I think any organization could take a look at it and say, I don’t just want productivity. I want to unleash the creativity of my people towards new outcomes. And that’s the kind of work I want to work on. I think it’s the kind of work that you want to work on. And it’s the kind of work that I think that the Pope’s encyclical talks about, which is meaningful work and placing humans in the system and not just this sort of technocratic cost-out perspective.

Jorge: Yeah. There’s been a, well, you wrote a post about this and I want to get into the post.

Greg: Yeah, sure.

Jorge: The very title of the post has the phrase, “The feature is dead.”

Greg: Yeah.

Jorge: Which is kind of provocative, right?

Greg: Yeah, sure.

Jorge: Why is the product feature dead, Greg?

Greg: Well, I think we’re designing something different now, right? Feature was a component, a widget, a tool that helped humans solve a problem. And in the traditional way of product development and user experience, the actor was the user, right? The user’s on a journey. You build a capability for them to complete a task that’s important for them. They use that tool. They get it done. And so product development would think in increments of capability, features. That’s what we call them in product. And we would build those features in support of customers accomplishing their goals that were important to them on their adventures at work. And what’s changed now is we have this intelligence that we’re working with. And it can be the actor, right? It can make the choices and decisions on the process, especially when you think about more agentic workflows. And so the notion of product discovery and creating and making is different. We’re not making a widget or a tool. I mean, those are still important, and by the way, yes, thank you for calling out it’s a provocative title. Features don’t disappear; they still are important. But I think what’s more important is encoding the intelligence in a system so that it can support humans and their goals, but also allow some autonomy for agents to do things. And that’s a new skill, a new pattern. And the way I was thinking about it is Clayton Christensen coined this term jobs to be done. And jobs to be done is sort of evergreen. It doesn’t go away. You have to balance your checking account or you have to pay, make payroll, or you have to answer a customer call. But the way that you can do that can change over time with the way technology shows up or how an organization chooses to solve that problem. And ironically, a lot of organizations don’t actually really understand what they do. They’ve built sort of Rube Goldberg machines of technology that allow them to accomplish tasks, and individuals in the organization are actors in that to solve a business problem. But very few people in the organization actually understand the outcomes and business goals that an organization is trying to solve for. So I’ll give you an example. The reason why this came up is there’s also something very different in the way that we can build software right now, where it’s more structural and more of a system and less bespoke custom feature development. So this particular startup that I’m working with, we are building a system that can add new capabilities, and we wanted those new capabilities to show up almost like a feed of content, right? The application would be much more like Spotify, where you’d have a playlist of things that you can, instead of a playlist of things you listen to, a playlist of things that you can do. But to do that, then you have to kind of understand, like, what do those things do and why are they valuable and how do they achieve outcomes that are important for the end user or the company that’s buying a product or a service. And so we built this thing. I’m calling it a job brief. It’s a little bit of a hybrid. It’s influenced a little bit from the Josh Seiden sort of outcomes over output construct, being an outcome-centric notion. But what I wanted to do is try to create a recipe. And I built this sort of recipe card. You can’t really see it here, but I’ll share this with folks if they’re interested. And it was really very straightforward: find the job. What is the problem? Sit with a practitioner or a person at work and find out what is the thing that they need to accomplish. Write a job statement, one sentence: who’s the user, what are they trying to do, whether they want to know or decide. Don’t make it about technology at all. What’s the outcome that they’re trying to get to? And then the next layer, which is new, I mean, this is something we’ve done forever, but the next layer is what is the context that we understand in the system? What data do we have access to? Where is the user or the person who’s acting in a moment in their day, in their workflow, in the ebb and flow of an organization? You have to define what done means. When the job is completed, what does success look like? And then the last part of it is really understanding what expertise is around that. And working with people who have deep knowledge of what that outcome should look like, what’s meaningful for an organization. And I would argue that for every organization, that expertise might be different based on the values of that organization, the people they have, the things that they find important. And this is an opportunity to add that human layer into what differentiates company A from company B. Don’t just use a novel solution that everyone uses. Build something that’s respectful of what’s important to you as an organization. And then finally, the last part is find some way to measure it by how often it’s used, by invocation, like how often it gets done. And so that construct is really about understanding how humans in the system work. Now, I’m not naive. Some of this work turns into agents that do the work for you. And ideally, in an organization, you could use this as a way to look at the things in your organization that you can codify, the domain expertise, to gain productivity and to gain efficiency where you can. But my next point of view on that is in service of being able to do more interesting, more valuable work that pushes your objectives farther forward. And so that’s the notion behind it.

Jorge: This is all in the context of design and the projects that you have been working on. You’ve been working, your role has been like a fractional chief design officer, right? So you’ve been leading design teams. Another one of the signals that we are picking up from the environment is that it feels like many organizations are questioning the value of investing in design.

Greg: Yeah.

Jorge: And I was thinking, there was a time when a lot of organizations did not have big design teams internally, right? The idea that design is a function of the organization, I would say at least the current wave, because there have been prior ones, but the current wave, we can probably date back to around 20 years ago after it had become clear that Steve Jobs had saved Apple through design, right? And people were upholding the iPod as an example of a well-designed product. And there are still business leaders out there who are thinking in terms of, like, I want something that is as useful, beautiful, whatever, as the iPod, right? So it became like a touchstone that articulated the value of design for organizations. And that seems to have shifted significantly as a result of AI. And I suspect that it might not be coincidental that Jony Ive and company’s latest product to hit the market has not been well received by a lot of people. I’m talking about the new Ferrari.

Greg: Yeah, right.

Jorge: And I have no, you know, I’m not an expert in that space. I’m not a Ferrari fan or anything. To me, it looked like—

Greg: I lost your audio. Oh, no. I can’t hear you. Now I can.

Jorge: Okay, great. What I was saying: I am not a Ferrari fan, so I don’t have as strong feelings about that product as other people. But it did strike me that at least a lot of the commentary I saw online, I got the sense that it felt like this, like it was over-designed or like it’s precious. Or it’s like it’s a product that is trying to make design, like it’s a design-forward thing. And in some ways, that almost hurt it because it feels like it’s a rethinking of what a Ferrari is supposed to be. And I almost found it to be like a metaphor for what’s happening elsewhere in design. It’s like, I guess the question is: is design necessary now that there’s a Claude design and Figma will do design work? And I think that I’ll stop after this. I think that a lot of organizations have built design functions that are primarily production functions.

Greg: Yeah.

Jorge: And by production, I mean they are set up basically to crank out screen-based experiences.

Greg: Yeah.

Jorge: And they have staffed up with people who are tasked with doing that kind of work. And at least to me, it’s been pretty clear that that’s going away, and it has been clear for a while, right? The tools have been getting better. The kind of design work that you’re talking about when you talk about job briefs. You said that the jobs-to-be-done construct is evergreen. And I think that one of the reasons it’s evergreen is because it moves the level of abstraction. It’s not about how do you execute on the hole in the wall. It’s about how do you determine what it is that the customer needs. And then you can figure out how that’s delivered to them, right? And I’m wondering, I’m just, again, this is open-ended and unstructured, right? So I’m thinking out loud here. I’m wondering if what we’re seeing is a shift from an understanding of design as this kind of screen-level production function to, and then there’s a question mark. And I think that your article tries to answer that question by saying to a role that is more strategic, which is something that designers have been trying to do for a while with not a lot of traction, I would say.

Greg: Yeah, many haven’t. Yeah, there have been some examples of people who have, but yes, you’re right. Let me respond to it. I think when we build products, there are different roles that are really important. And I think when design is seen as only craft and only as screen building, it misses the value that design can bring to the table. Those things are important, but they’re not the only thing. And the challenge is that at some level for many people in many organizations, the AI tooling is capable of doing, I wouldn’t say excellent, but reasonable results on the sort of production-level quality of building a user interface. However, I think one of the things that designers bring to the table is a deep understanding of human behavior and building products that recognize humans in the system and the mental models that people have. And it’s connected to empathy. It’s connected to having the ability to do ethnography, basically sit with customers and understand how they solve problems and what they’re trying to accomplish. It requires some new skills now because when we look at the capabilities of these tools, you can incrementally make things better or you could radically change things. And it doesn’t mean one or the other is the right path. It’s actually what is the right path for the group of humans that you’re responsible for delivering a solution for. Too much change may require a group of people to do things they’re just not unwilling to do or unable to do cognitively. Not enough change is a missed opportunity toward functionally changing the game in a way that produces some really interesting results for an organization or for the people who work in the organization. And we’re in this really messy period where the old rules don’t really apply and people are trying to apply the old rules. So you still see PRD, product requirement documents. You still see engineering burndowns. You still see JIRA tickets created. You still see, this is a software development process, because people anchor to that. That’s what they know. They kind of organize around it. But it’s unclear to me if that process of how we built software is still usable and useful in this new moment. And there’s an opportunity to change that. So where am I going with all this? I think designers bring a couple of skills to a team that are really valuable. And if not there, it’s a missed opportunity for organizations. And they can be very strategic. We are adept at the art of juxtaposition. We can take two different ideas and put them together and discern a net-new outcome. Because we make the think, we make things, we make artifacts, and those artifacts inform us. And that conversation we have with the things that we make allows us to find truth or an answer or a solution or a novel way of solving a problem in a way that can be faster than other methods. It’s not the only way to solve those problems, but it’s a super valuable way to do it. So that’s kind of just one path that designers take. The second part of it is I think it is my personal perspective that it’s inexcusable that you don’t make things great now because the tools let us do that. And that requires discernment. That requires someone who can look at a small radius or a small curve on a user experience or looking at accessibility and making sure that a product is useful for all of us, regardless of our abilities. That we can choose words carefully so that it aids people in the direction of the path that they’re trying to take. We don’t just build a piece of software and expect them to learn how to use it. We can now frame a product in a way that fits the mental model of the people that we’re serving, and we can actually get closer and closer and closer to that because these tools allow us to actually iterate and understand that more successfully. So I guess a long way of saying is I think designers are very important. There are some new things that we have to look out for, like I think interfaces are starting to collapse. We’re doing more of our work in language models, right? We’re speaking with AI. We’re having a conversation with AI. AI systems can not only answer words, they can answer in interfaces, so they can create custom experiences for us or custom tools for us in the conversation. You could just do that. But I think the thing that design brings to the table is an intentional way of doing it, shaping the grammar of an organization, inserting a value set of values into an organization, shaping how answers are delivered. Are they long? Are they short? What’s the structure? What’s the organization of them? Left alone, a large language model may choose to answer a problem differently every time you ask it, and that may not serve the audience that you’re trying to serve, right? So I think there’s a role for design to be very much involved in intentional curation of these experiences and bringing human values into them explicitly. I remember, I’m forgetting who told me this. I’ll think of it in a moment. But all software has opinions in it, whether they are explicitly or implicitly embedded in the software. Some teams are very explicit about it: this is what we do, certain things. Others, it’s just the end result of the people who built it and what they valued. But it’s there, right? We have an opportunity to be very explicit about how we serve people. And again, I think design is the discipline that not just solves business problems but figures out ways to make it deeply human. And I think our opportunity is to help organizations at a different layer, at a different level. And it may not be screens we’re working on. It could be orchestrating the flow of how work happens in a way that makes sense for people. And that’s a new skill. Not all designers are going to pivot or understand how to move into that space. But I think the things that we bring to the table are very useful there. Anyway, that—

Jorge: Was a long answer to your question. Well, and it kind of prompts some follow-up questions. You said earlier in the conversation, and I’m going to be—

Greg: I lost you there for a second there, Jorge. I think your internet took a—

Jorge: Yeah, something’s glitchy. Can you hear me?

Greg: I can hear you now, yes. I wanted to repeat your question or insight.

Jorge: Yeah, so you said, I’m going to paraphrase and probably get it wrong, but you said something earlier in the conversation along the lines of one of the things that we’re grappling with, and this was talking about as designers, is the fact that many of the things that we were doing as humans working with tools are now being delegated to agentic systems, right? And I’m going to put on my CEO hat, right? Like I have to make, I have to determine how I’m going to invest, how I’m going to allocate the organization’s capital, right? And there’s a lot of incentive right now for organizations to invest in capability, like technical capability, right? Compute is what they’re calling it, right? And you said that one of the things that designers bring to the table is a deep understanding of human behavior. Yeah. But if the systems that we’re building are not going to be used by humans, why does that matter? If I’m a CEO looking to invest, what’s the argument in favor of investing in a design team that is going to be crafting experiences to be used by humans? When, hey, isn’t AI going to do all of it? Why am I investing in human experiences?

Greg: Well, I mean, that’s a great question. I think if you’re a cost-out CEO, that may be what you think about, right? You’re like, I don’t need a design team. We’re going to use all these tools, and we’re going to deliver this service with as few people as possible. And we’re going to look at generating as much revenue as possible. And this is a path for us to get there. And my guess is there’ll be many parts of our economy that are going to be efficiency plays like that, that are going to be things that people are worried about from a job perspective. And it’s sort of inevitable. However, I also think that there will be a group of CEOs that have a growth mindset who look at what their organization does in their community or wherever they serve and look for opportunities to provide better services or better outcomes or better products. And I think one of the things that’s missed is there’s this bottom-up and top-down conversation that’s missed. So as an example, I think small organizations benefit massively from these tools because they allow them to punch way above their weight so they can compete at levels that they couldn’t compete with before. And small, intimate teams with these tools that communicate well with each other now have the ability to expand their horizons around the things that they can offer, the services they can develop, the things that they can provide for whoever their customers are, or users are, or whatever their goals are, whether they’re for-profit, not-for-profit, etc. In large organizations, I think the transition is going to be identifying also where in the aspect of the services that they provide that humans are actually important for their customers, right? So I think as humans, people want to hang out with people, right? And I mean, there are people apparently who have chat, cheap, and girlfriends, but I think most of us are, especially even post-pandemic, and I still think we’re in the post-pandemic phase, we want to have a sense of community and connection to each other. And so I think there’s huge opportunity for organizations that recognize how to place their people front and center with their customers or the people that they care about or the things that are important. So I guess what I’m trying to discern is I think there’s an opportunity space for the people who are good at unlocking possibilities and discerning new things to service, developing better outcomes for all of us. And it’s a little bit of a, you know, it needs to be seen, but I think that’s the path that I want to see. I would love to see our politics in this world focus on the opportunity to service and support everyone. I’d love to see our businesses look for opportunities to grow their businesses in new and creative ways. And I would love to see human potential be the big story about being unlocked by these tools versus being laid off. And I think we need to think about that very hard. I think we need to find this is going to be a transition. There’s not going to be without, there already is massive transformation going on in organizations. And I think we are, as a culture, need to be managing this carefully. And again, I’ll come back to why I think design is important, because I think designers can find opportunities to potentially mitigate some of the challenges with AI, from an employment and cultural perspective. But they’re also just going to be great at finding new things to do that we didn’t know we needed before and that are exciting and fun and fulfilling and helpful. And so, if I were a large CEO, one of the things I would be investing in is a creative design team that is just exploring and looking for net-new things that could benefit, that are adjacencies to a company’s core mission that might be new growth opportunities for them. And I think that the tooling allows creatives the opportunity to really shine there. I don’t think we’re there yet. I don’t think people have talked about it yet enough. But I do think that there’s really an opportunity for us to look for ways to be more future-focused and actually try to tackle some of the real problems that we have in the world.

Jorge: I kind of want to double down on what you’re saying there, because in playing devil’s advocate earlier, it may not have been clear just how much I agree with what you’re saying there. But my read is that organizations that are kind of restructuring themselves to maybe, like a phrase that you could, maybe a phrase we could use is something like a post-design world, or like a world in which they’re not placing their emphasis on human experience, right? The organizations that are investing in AI as a way to gain efficiencies by automating the sort of touchpoints that humans have relied on so far, they’re doing so from what I see as like a, like in my mind, I have this Venn diagram that has fear, bad incentives, and a kind of like spectacular lack of imagination. Yeah. The phrase that often comes to mind is this Warren Buffett thing where he says that he advises being bold when others are fearful and fearful when others are being bold. And I just want to kind of double down on what you said about this being a time of unique opportunity, particularly for the organizations that are willing to zag where everyone else is zigging in the direction of efficiencies. Just because there are, like to your point, there are now possibilities that were just previously unavailable. And to only think about the path of, like, how can we make, how can we deliver the minimum possible experience as cheaply as possible is one possible direction, but by no means the only one, right? And I suspect that we are still in the throes of, like, hey, this is a new technology and let’s double down on efficiencies where we have not yet truly explored the possibilities of other ways of using the technology, right?

Greg: Yeah, I mean, I love that framing. I’ve been a big, one of the things I’ve talked about for the last 10 years is this notion of incrementalism versus really understanding the problem, right? And for a lot of organizations, incrementalism was the path towards success because you took small pieces and you got better and you got better over time and you got better over time. It kind of fits the Agile Manifesto. It’s how organizations work. They’re risk-averse, so they don’t want to try to take on too much. We’ll make one small change, we’ll make a change of, you know, and. But it was connected to the fact that things were very difficult to do well, and therefore you had to be careful about doing it. And so instead of going for it and doing something big or trying an experiment and failing, you just made your product slightly better over time or your outcome slightly better over time, your system slightly better over time. And there’s nothing wrong with that as a strategy, by the way. It makes sense and allows you to do things in a sustained way. What is interesting about this moment is that these tools allow us to build things that used to be very, the very expensive part of building software is far less expensive than it used to be. And so an incrementalist mindset may just be a faster way to get to the wrong place, you know? And I think one of the things that we don’t do enough of is discovery work, understanding what is the problem and what would really be meaningful for people. And now we can spend a lot of time in that, right? And in the design space there’s this diagram called the double diamond that came out of the British Design Council that’s a very popular way of describing the process of design. And the first half, the first diamond, is discovery. And then you sort of evolve that into a product, and then you go into an execution phase, and then you deliver and you learn from your customers. And my argument now is that these tools allow us to build the first part of that diamond much bigger and the rest of it much smaller. And what do I mean by that? It means that we can spend, in a short period of time with these tools, we can learn way more about who we’re serving and have a much better understanding of what their problem is and iterate on not just one, but hundreds of solutions that could possibly satisfy those needs and outcomes, and then discern which one is the best, refine it, make it great, and then deliver it at fairly low cost from an execution standpoint. And so that upends the process. It used to be the other way around, that the execution part was so hard that that’s where all the energy was, right? And so it was like, make a small bet, get it out to market, make another small bet, make it out to market. So it goes back to your point of lack of imagination. And I think there’s an opportunity right now for companies to at least have some part of their organization that is thinking boldly and broadly and unhampered by an incrementalist mindset. And I think if I were a CEO of a larger organization, I would be setting up a lab to think about not how to use these tools to do what I do better now. I would be setting up a lab on how do I use these tools to do something I’m not doing now that would help me grow my outcomes that are important to my shareholders or to my customers or to the business community that I’m trying to connect to.

Jorge: I love that framing.

Greg: And I think designers are great at that. They’re not the only one. There need to be other parties in that conversation. It’s a multidisciplinary effort, but it doesn’t work without designers in the room.

Jorge: You know, to circle back to the Pope’s encyclical, the central metaphor that he uses to talk about the possible ways forward for the development of AI-based systems, he uses this architectural analogy from using two stories from the Bible. One story is the construction of the Tower of Babel, which is a kind of technocratic, top-down effort to, now I’m kind of reading into it, right, to control. And it’s an effort that kind of flattens differences between people. And he contrasts that with another story from the Bible, which is the rebuilding of Jerusalem after it had been torn down. And he talks about Nehemiah. I don’t know if that’s how you pronounce it, but this person who rather than dictate top-down this technocratic solution, gathered the people who inhabited the city. And through this kind of consultative approach, led to the rebuilding of this kind of organic, more organic city that responded to their needs. And part of what I’m hearing you say is that, and I think that this is also implicit, if not explicit, in the encyclical, is that AI allows for both of those approaches. We can do the top-down thing really fast now and really comprehensively, and it can turn into a real dystopia. Or we could employ it in this more kind of bottom-up, consultative, human-centered way, and it could also do it much faster with greater scope, with the possibility to explore many, many more alternatives just because the tool allows us to do so much more. So it becomes a matter of how do you choose which of the two approaches you’re going to take? And I think what we’re saying here is we would like to foster a world that follows the second path, the more kind of designerly path, the path that puts human beings, their needs, including their dignity, which is an important word in the encyclical, front and center. And the tools are amazing. They can empower us to do much more than before, as long as it’s in service of that, right?

Greg: Yeah, creating a better world. And the irony is you can have both of those things happen. The efficiency play can be in service of unlocking human potential, right? So they don’t have to be either-or paths, but they do have to be both at a minimum. If we just go the Tower of Babel path, I don’t want to live in that future. I’m very much interested in being intentional about the choices that we make. And again, that’s why I go back to why designers are important. We’re good at that. We are good at intentionally helping craft a narrative and artifacts and things which connect to the way that we want to live. And then we’re good at telling stories around that with the things that we create. Those things that we create inspire people. And it’s a really part of being human that there are things that delight us and bring us joy and make us cry and help us understand and live fulfilling lives, all the things that I think are important, which by the way, that’s not the longest list of important things, but nonetheless, I think we’re coming to a close.

Jorge: I was going to say that feels like a good place to wrap it up. If you want to follow our work, we do have a Substack. It’s called Unfinishe Thoughts, and it’s at thoughts.unfinishe.com. Remember, it’s Unfinishe without the D. And Greg and I post there periodically. It feels like almost as infrequently as we do these live streams, but we should write these things up more.

Greg: Yeah, our plan is to be a little bit more prolific in the rest of this year. But thanks for hanging out with us today. And Jorge, as always, I love hanging out with you and talking about our stuff. And we’ll see you at the next Unfinish.

Jorge: Same here. Thanks, Greg. Bye.

Product and design work is changing as organizations embrace AI. But how so? Greg explored this question in the third episode of Cindy Chastain’s podcast, This Moment We’re In.

His answers weren’t theoretical, but based on his experience as a fractional design leader, a role that allows him to perceive high-level patterns from a relatively impartial vantage point. This leads to important insights.

I’ll summarize the key ones here, adding my observations. Then, I’ll circle back to Greg’s parting recommendation — a framing that teams should start adopting immediately. Let’s get into it.

Roles are blurring

Traditional team boundaries between product, design, and engineering starting to blur. As Greg put it,

one of the things that was interesting in that particular group was we were moving away from a PM culture and an engineering culture and a design culture, or a design discipline and a product discipline and engineering discipline to a product culture that it was inclusive of all those roles, and that the who was what was situational and based on need.

This has upsides and downsides. On the plus side, team members can step in to perform others’ functions as needed. The result? Sustained velocity.

The main downside: a potential lack of alignment and control. But also, team members may find themselves making decisions outside their area of competence. Roles still bring discernment to the table, which is essential.

As an example, Greg recalled a case in which a PM vibe-coded a design artifact in a week. They were celebrating the fact this could be done at all, when a designer in the team observed they could’ve done it in four hours.

That a tool exists doesn’t mean it will be used effectively.

Two primary uses for AI

Greg called out two distinct modalities for teams using AI:

• As a way to increase velocity — i.e., doing the same kind of work, faster. Design is often framed as an internal service function, taking requests issued from other teams. AI can help design orgs provide this service faster.

• As a thinking tool — i.e., a medium that allows teams to frame problems, explore possibility spaces, and inform organizational strategy. This includes improving research operations and lowering the cost of producing high-fidelity prototypes.

Greg cited real-world examples of both. In either case, AI accelerated or increased scope. But — and this is critical — it didn’t replace the need for discernment and clarity. We’re squarely in augmentation (rather than automation) territory.

But it was the second modality where there’s most potential. Greg shared an exciting example from a recent engagement, where he worked with a small, distributed team to design a product North Star. Previously, such efforts were constrained by engineering bandwidth, but

That model doesn’t hold up as much anymore, and one of the things we learned in the process of doing this is not only could we move fast, we could insert more things into the process that were hard to argue for under tight time frames that made the product richer. So, when we’re in a sort of divergent phase, we looked at the information architecture of multiple competitors and deeply understood them very quickly, and figured out why they made those decisions.

…

Then, we built hybrids of those just because we could. And normally, you or someone would say, “Well, why are you doing that?” And I say, “Well, the juxtaposition of those things might inform us in a way that we haven’t thought about, and there might be an accident of doing that that might surprise us.” So, we did lots of that. And there were a couple of happy accidents in the process, where we were informed by a mashup of something that would have been very difficult and time-consuming to do, that really, you could do in like a couple of hours.

This isn’t just the same kind of work, faster. The ability to move faster changes what kind of work can be done. Designers explore solution spaces by making — “make to think,” as Greg put it. AI lets that happen at a different level.

Think jobs, not features

How can design and product leaders effectively navigate these changes? Greg suggested an insightful reframing: rather than think of the focus of design work as product features, think of the jobs that the product is meant to fulfill:

People never bought features anyway. They only bought outcomes. Features were a way to get to an outcome. But I think the artifact right now is the intelligence that you’re designing. And then, the delivery mechanism is also in flux. So, is our life going to converge on one of the large models and those become almost like operating systems for us? Or is there space for custom products that recognize and have contextual insight about us that make our lives more easy and more straightforward?

Which is to say, the capabilities afforded by AI open new possibility spaces that aren’t well-served by the “feature” framing. We must approach design at a more systemic level — known territory for designers:

At the end of the day, we benefit product teams by understanding it better. And we, as design teams, have been doing this for a long time. Think about journey mapping, journey mapping as a tool, a way to understand how a job was getting completed.

Christensen et al’s “Jobs to Be Done” framework provides an excellent conceptual foundation for this reframing. Check out Greg’s post on Improbable Futures for more on how this plays out for product and design teams.

Key takeaways

As a product or design leader, you must use AI intentionally. This conversation offered three key insights for doing so:

1. AI isn’t just a way to move faster. It also offers new ways for teams to think, unlocking strategic possibilities.

2. Humans still need to decide what problems to solve and prioritize those that matter most to the organization and its customers.

3. Leaders should use the tools themselves. Don’t assume you can delegate hands-on experience to your team. Work with heavy adopters to enable new ways of working.

In the interview, Greg said he wants to disrupt himself. That doesn’t mean starting anew. Instead, it means learning how new technology plus experience unlocks new possibilities. As he noted, our work at Unfinishe reflects that value.

This is an exciting (and unnerving) time. It’s important that seasoned leaders like Greg and Cindy share their experiences implementing AI at scale. If you’re a product or design leader, this conversation is a good investment of your time.

Check out This Moment We’re In wherever you get your podcasts or on YouTube.

Leadership entails acting intelligently — i.e., moving in the right direction for the right reasons. This requires seeing clearly. Tools can help… or they can make it harder while seeming to help.

The question is, how do you do it? I’m a big fan of understanding the technology firsthand. But we must also understand how the technology changes the nature of the work.

AI calls for moving up the abstraction stack. It’s similar to what happened with computer programming, which went from flipping bits to assembly language to higher-level languages and now coding agents. The question before design and product leaders isn’t whether this shift will happen to design: it’s whether they’re ready to lead at the right level.

A bifurcation is coming. The organizations that figure out the role the technology plays in this shift will thrive. Those who do it poorly will crank out work faster — but it’ll be increasingly misaligned with the business’ need.

As I said near the end of the episode: if you come out of any of these conversations feeling like you’ve got the answer, you’re probably wrong. The technology is changing too fast. What you can get is a clearer read on the context. Hopefully, this conversation helps.

Finding Our Way, Ep. 69: In a World of AI, What is the Work Really About?

This post first appeared on jarango.com.

In the second of our “Open-Ended” livestreams, we discussed the anxiety many design and product leaders are feeling from AI-driven changes. The intent wasn’t to offer suggestions, but to think out loud about what we’re observing.

That said, we surfaced a couple of important insights:

• Organizational structures must change. How? Greg suggested empowering smaller (e.g., two-pizza) teams with enough agency to move and learn quickly.

• In response to the “AI will replace SaaS” narrative, Jorge countered that for many products, information architecture is the moat.

We’d love to know what you think; please leave comments in the YouTube video.

Links

We referenced several articles and at least one book during the conversation:

• The cognitive cost of AI by Giu Vicente

• Why AI Adoption Stalls by Keith Ferrazzi, Wendy Smith, and Shonna Waters

• The A.I. Disruption We’ve Been Waiting for Has Arrived by Paul Ford

• Welcome to the Intelligence Era by Craig Hepburn

• Managing Priorities by Harry Max

Transcript

(AI generated.)

Jorge: Well, hello Greg. I think we are—let me refresh—yep, so we are live, sir. It’s good to see you.

Greg: Nice to see you, Jorge. Happy Thursday!

Jorge: Happy Thursday to you as well. I’m having a weird echo.

Greg: Well, anyway, we’re here today to talk a little bit about what’s going on with sort of this zeitgeist moment. It feels like there are a bunch of messages kind of moving through our communities. Jorge and I have been talking a lot about this stuff, and we thought we would get together and run one of our Unfinishe sessions—Open-Ended is what we call them—but I thought maybe we could start and talk a little bit about Unfinishe, and then we’ll get into today’s topic, which is really about the psychological tax of AI initiatives and how all of us are feeling. But before we do that, Jorge, what is Unfinishe?

Jorge: Unfinishe is an emergent practice that you and I have taken on to develop to help teams navigate this new era. I think that that’s kind of like the highest level description that I can offer. What teams might mean might be up for grabs; it’s emergent, right? But we are trying to be responsive to what we are hearing in our various communities and contexts. It’s very clear that everyone is cognizant at this point of the fact that we are in a different space. This technology is massively disruptive, and it requires new approaches and new thinking, so that’s clear. The other thing that’s become increasingly clear is that many of us—and I’ll put you and I in this—are trying to come to grips with how to navigate this time skillfully. You and I bring particular perspectives and life experiences to bear on this problem that we believe are helpful to folks. So that’s my kind of 10,000-foot view on what Unfinishe is. What would you answer? How would you answer that question?

Greg: Yeah, I mean, I echo what you’re talking about. I think part of it is the opportunity to disrupt ourselves and explore the meaning of these new tools and do it in a way where we can sort of be all in, but at the same time be intentional and try to understand what it might mean, and then share what we learn with folks. I think we named this endeavor Unfinishe with the ‘D’ missing on purpose because I think one of the things that we’re all experiencing is that the moment you feel like you’re on solid ground, the ground shifts, and we need to find an understanding of what to do next. I think the journey we’re on is to help organizations and teams navigate that. We’re taking the experience we’ve had in our careers, but we’re also super willing to experiment and adapt. We’re trying to be curious and mindful in the practice. So that’s how I might answer that. Maybe that’s a good segue for today’s conversation, which is, you know, there’s a lot of anxiety around what’s going on with these tools. We’re starting to experience it in our own work, but we’re also seeing it in the teams that we help. There seems to be a conversation bubbling up in the zeitgeist around AI right now about what it might mean. I think there are also some seminal moments that have happened recently that have demonstrated that we’re actually in a new place. You know, this isn’t the announcement of ChatGPT two and a half years ago. This is the arrival of coding tools, the rapid improvement of the models, and the fact that we’re now starting to see teams use these things. There have been some really salient conversations around that. So that’s what we’re starting for here today, and we want to help and have a conversation around it. Also, folks online, you’re welcome to come and ask questions. We’re going to try to be vulnerable and transparent, if possible, about our own insecurities and feelings. This is an experiment, and we’re glad that folks are here with us today.

Jorge: And for a bit of context for folks who, for whom this might be the first live stream of ours that they join, this is only the second one that we’ve done. Right. And in the Unfinishe spirit, this is a very open-ended conversation. It is very loosely structured. I would say there are not going to be any decks. There are no pitches. That’s not what we’re doing here. What we’re doing is we’re trying to think through the moment that we’re in, and we’re trying to think out loud. Because the time does require kind of fast responses, I think that we can’t be too precious about what we’re doing right now. So with that in mind, you said that we want to be vulnerable and that we’re both feeling a bit of anxiety. I’m going to kind of pinch and zoom on that. The live stream you titled it “How Are You Feeling?” How are you feeling, Greg?

Greg: Yeah, I mean, there have been a couple of articles that have encapsulated my experience lately. I would say I’m both super intrigued and excited and super freaked out at the same time. And what do I mean by that? I mean, I’m enamored by the capabilities that I have at my fingertips and blown away by the things I’m able to accomplish with the tools that I’m using. I’m also recognizing that I don’t have good boundaries with how I operate with Claude, which is the tool that I use, Anthropic’s AI. At the end of the day, my brain is like, I’ve gone through a lot of work, and I’m wondering if it’s sustainable. I’m mixed about all this stuff; it’s exciting, and I’m enabled to do some really incredible things. But at the same time, I’m trying to track if I’m being changed by this experience.

Jorge: It might be worth calling this out because some folks tuning in, this might be the first time they hear from you. I think that we have slightly different backgrounds. I would say that your background, your trajectory, and your career has been mostly around design leadership, very senior roles, managing teams and organizations, whereas my background is more as an individual contributor for hire. I’ve been a consultant for the bulk of my career, and I’ve been brought in to do very specific things. I’m just calling that out because I hear you talk about this being torn between excitement and apprehension, and I’m feeling like that too. But I think I’m feeling like that for maybe different reasons than you are. How does this tension show up in your work as a design leader?

Greg: Yeah, I mean, I think there are a couple of things. Paul Ford wrote something recently about feeling obsolete at some level and at the same time superpowered. Right? I have some of those feelings. I’m able to help a couple of companies right now from a design leadership perspective, and I can help them in really fast ways that would have taken weeks to accomplish, and I can do it in like days. That’s really great, but at the same time, it feels like the flattening of my expertise. It’s an interesting moment to see how we show up. I think there’s some anxiety around that. I might flip the bit for you, and you’ve been spending decades thinking about how humans navigate information. Does AI feel like an extension of that work or a threat to that work? How does that fit into how you operate in this moment?

Jorge: Well, the first thing that I’ll say here is that anything I say today, I say with more interest than conviction, meaning my mind is still exploring this, and I’m trying to develop my positions. What is very clear to me is that large language models in particular change our relationship to information considerably. I realized this; I’ve been working with AI—in general, what we call AI—for a long time with client projects. But when ChatGPT was released, I kind of went all in and said, “Okay, let’s see how this can help me do the work of an information architect.” It became very clear to me very quickly that the work I was doing needed to change and was going to change. You talked about acceleration as one of the things you’re experiencing in your design leadership role. I also felt that this is going to greatly accelerate certain processes. It’s also going to change how we interact with information. The object of the things that we design is likely going to change, but that might take a bit longer. I don’t know that I felt as threatened; I’ve felt more excited. I’ve been more excited than I’ve been threatened, I think, by all this stuff. There’s a flip side to it, which is the fact that there’s a lot more information being generated. Not all of it is useful, perhaps. These tools have the potential to generate a lot of misinformation. But this is the kind of upside bit. I might sound like I’m taking a very kind of positive perspective here. The more I worked with these tools, the more evident it became to me that their effectiveness is highly reliant on the information that you are giving the tool. Initially, there was this idea of prompt engineering, and then people realized it’s not just a prompt; there’s more stuff that you’re feeding the AI. The phrase became “context engineering.” To me, the upshot of all that is that language models are as useful as the information that they’re given to work with, and I suspect that people who do information architecture work have a big role to play in creating and structuring the information that gets fed to the LLMs. That’s going to have a very important effect on the degree to which the systems produce good results. So I’m excited. It is a time of great change, and great changes always produce anxiety, so I’m feeling anxious too, but I think I’m also feeling like, my gosh, there’s so much potential here—unexplored potential, right?

Greg: Yeah, and I think you and I did a consulting arrangement last fall where we helped an organization sort of organize their business information. I think you’re right that there’s this notion of understanding how work gets done and what content exists in an organization. Most organizations can articulate that very well; they just kind of tacitly know this is how they operate. These systems work better if you can be clear and crisp about the terminology. I’ll use a fancy word: the ontology or the model of information in it. I think for folks like you—who I love the fact that you called yourself an architect of information now versus an information architect…

Jorge: An architect of intelligence.

Greg: That’s right, architect of intelligence. I think there’s some truth to that because I think one of the things that we need to talk about—one thread that needs to be in this conversation—is to be intentional about how you use these tools. One way to alleviate anxiety is to understand the structure of the entity that you work for, the organization that you work for, or the thing that you’re trying to accomplish—so that you can make conscious decisions when you interact with these tools, and then you know your intent. That’s where these tools are actually really valuable. If your intent is clear, the quality of the answers that they generate or collaborate with you on improves, and that’s where you can start to have a conversation that leads you to new insights or new outcomes. That’s the part that I think is super fascinating. Every day I’m surprised by something. There’s something I’ve done, and I’m just sort of like, “Oh my gosh, how did I do that? Wow, how did it do that?” That’s part of it. Is there something that you’ve noticed about yourself, though? Have you changed at all in terms of how you’re operating with these things?

Jorge: I’ve always been very hands-on with the tools that I use, and one of my directions early on with this stuff was I did not want to learn about it or just learn about it in the abstract; I wanted to have hands-on experience. I think that I’ve been maybe more hands-on with code than I have been more recently in my career just because I’ve been really trying to lift the hood on this stuff to get a sense of how it works. You referenced the Paul Ford op-ed piece in The New York Times earlier. We have been having conversations with other folks and also reading stuff that people have been publishing. One of the things that I read in one of the articles that you and I were discussing on Slack over the last week or so is something that resonated with me, which is the idea that all of a sudden you have this tool that lets you do so much stuff that you tend to fill your day with stuff. It’s the kid in a candy store thing where, left unchecked, you end up with a really bad bellyache. I don’t remember which one of the articles it was. I think you shared this one where this person was saying, “You know, it’s taken over. Now I’m thinking about it during my lunch break and thinking about how I can prompt this thing.” Or, you know, “Before I go to sleep, I want to leave it doing something overnight.” There’s so much potential. All of a sudden, there’s an unlocking of so much potential that we want to—well, and then there’s the incentive to move very fast, to take advantage of that potential. We run the risk of not leaving enough space to be mindful about what we’re doing, to prioritize what we’re doing. I’m saying this because I am feeling that. I’m feeling like there’s so much that I can do. Let’s do it all! Now that we have these things that can do it for me, I’m feeling a little burned out by that. I’m suspecting that other people are as well based on what I’m reading.

Greg: Yeah, I think that, first of all, we’re hitting a cognitive barrier. I mean, humans can only process so much information. Individually, I think there’s a challenge. I’m feeling exactly the same thing. I generate, you know, I’ll take some information, I’ll process it, and I’ll work with Claude to tune it up in a way that makes sense to me. I’ll get a very professional document. Part of my process is I usually print them. I know it’s very old school, but I find that I don’t edit very well if I’m just looking at a screen. If I look at a piece of paper, I can distance myself for a second and read it, take some notes, and then go back, and that’s kind of the way that I operate. But I’m starting to build these very useful and deep content pieces for the customers that I’m working with that are highly valuable. But I’m filling my day with like doing that work. Earlier in our conversation, I was talking about how sometimes my brain is just like, “Oh, I’ve done… I can’t process it anymore.” One thing I’m noticing—I don’t know if others are noticing this online, but if you are, let us know. One of the things in organizations is the socialization of ideas. We’re used to operating, especially in product development teams, at a certain clock speed. There’s a group of people who start working on an idea, and they start building prototypes and making, and they’re learning in that process. Then they need to bring other people along as that idea starts to gain momentum to empower those people to contribute to or execute aspects of that idea or that project to move it forward. Part of that is human nature; you want to co-create and be a participant in it. Part of it is you need to understand the decisions that have been made so that you can operate and feel like part of something. I think the velocity that some of these tools allow you to operate at is not just about the individual’s cognitive ability to manage; there’s anxiety around it that fits the organization’s ability to grok or understand and then ingest so that they can focus on, “Okay, this is how I can contribute or I can join the conversation.” I worry about that because I feel like we haven’t learned good boundary skills with these tools. It’s a little bit like a version of doom scrolling where you generate an endless amount of stuff. How much of it is still relevant the next day? Maybe not as much as you think, right? I think that I have some anxiety about being in that. One of the things I’m anxious about is that we’re going to have to learn new behaviors to manage that. What does that feel like, and how does that change us? A lot of people talk about discernment; that’s an important skill. Anyway, it’s a long-winded way of saying I think we’re only capable of grokking so much in a day.

Jorge: Yes, and I think we’re talking about it kind of at the individual level, right? We can do all this stuff, so we’re doing it all, right? There is an organizational variation of this, which is we have this design or product team which maybe is not growing. I see some folks posting job openings on LinkedIn, but if anything, I think the tendency has been for teams to shrink. All of a sudden there’s an insurgent request for new features and capabilities. There’s this drive to AI all the things. You have AI, so it’s easy to do, right? It’s like, no, it’s not easy to do. Now we’re overloaded with stuff. I’m thinking you were talking about this and our mutual friend and my podcast co-host, Harry Max, wrote a book on prioritization, right?

Greg: Yeah.

Jorge: What you’re pointing to is that we need to, on the one hand, move fast because this does indeed call for a fast coming to grips with the capabilities and constraints of the technology. But we need to do it in a way where we’re focusing our energy, our limited resources, on the things that matter most. It feels to me like right now, for a lot of organizations, at least from what I’m hearing, there’s not very good prioritization happening. It’s more like let’s throw everything against the wall and see what works coming out the other end. I’m kind of making a note here; that might be one practice that we could encourage folks to do to be more conscious as a team of the things that they are taking on and to take it on with the dual purpose of building useful things for people—obviously, we want to create value—but we have to keep in mind that part of what we’re doing here is also becoming competent with the new tools.

Greg: We have to create new skills, yeah. I think you’re—oops, I just unplugged myself. I can still hear you, though. Okay, I’m back. I think you’re right. One of the things that I think many teams are struggling with is that these tools also allow us to do each other’s jobs, right? So the notion of a product organization creates a lot of anxiety around that. You know, I’m a designer, but the engineering team can now write code for the UI. I’m an engineer, but the design team can now write code. I’m a product leader, and I can do both of those things. I’m a designer who can write a PRD, right? Those are very specific to the product development process. The notion of how we work is also in radical change because the boundaries between the disciplines are fuzzier. We need to be open and in a conversation around exploring it together versus in our disciplines; at least that’s my belief. I led a workshop with a client recently on who does what, how, why, and when? It wasn’t really to say that design only owns design and product owns product and engineering owns engineering; it was, “Hey, these tools allow us to be in each other’s camps.” There may be appropriate moments for us to be in each other’s camps. We don’t have the capacity to do something with the staffing we have, but as a team, we can use these tools to help us fulfill that capacity. We need to be in dialogue about that. One of the things I’ve learned is that discipline and having expertise still really matters, right? Discernment is a powerful thing. Just because someone can write code doesn’t mean the experience is a good one. Someone who has the ability to look at that and say, “Here’s how I might modify that because I have expertise in this area” is valuable. Similarly, on the product side, product market fit is still required—just because you can ask these tools to help you find product market fit doesn’t eliminate the need to have people on the team who have experience in bringing products to market, working with customers, and understanding how you create motion and market demand. All the things of modern product development or building things are still in play. But we have a lot of anxiety about whether our roles are still important. Going back to your central point, I think smaller teams are probably what’s going to be. Smaller, more empowered teams are going to be the future, and the smaller, more empowered teams can punch above, using a boxing metaphor, their weight. There are two reasons for that: one, because the tools allow you to do that, and the second goes back to my notion of cognitive dissonance and being able to communicate as a team. You need to have the intimacy of a small group to be able to share your thinking at the speed that this thinking is happening. It starts to break down if you’re in a larger organization that has organized people doing pieces of the work. I think the future is more empowered teams with more agency and clarity about what they’re about, and then just let them do their thing.

Jorge: And smaller—I heard you say as well, right?

Greg: And smaller, that’s right.

Jorge: Yeah. Do you have like, we all know about the two pizza team—the Amazon pizza thing. Do you have a size in mind?

Greg: Yeah, it’s not bigger than that. I think the notion of the two pizza team is that you all know each other, and you have a human relationship with each other, right? You have the ability to communicate and anticipate and complete each other’s thoughts and know who’s good at certain things. I think it breaks down once you go above that.

Jorge: I wanted to circle back to something you said because it made me shudder a little bit. You said something like designers are writing PRDs, and all of a sudden, we don’t need as much expertise because we can all do these roles.

Greg: Yeah.

Jorge: One bit of caution that I would drop in here is that a common mistake that many people make is to confuse the outcome of a piece of work—the artifact that comes out the other end—with the value of the work. I’m thinking of an exercise that I was part of many, many years ago, which is something a lot of designers have done. We were part of this workshop where we locked ourselves in a conference room for two days and made this enormous wall-sized journey map, right?

Greg: Yeah.

Jorge: The artifact that came out of that diagram was valuable per se because it informed a lot of important design decisions. But the artifact was only part of the value that the company got out of that. The other part of the value was the alignment that happened by getting a group of—I think it was like 24 people—to work together for two days building the artifact. If you could just prompt Claude to feed it a bunch of research and then say, “Draw me the journey map for this thing,” you might get a really useful diagram in the end. It might even be better than the one that the people put together. But you’d be missing out on the opportunity for people to use the artifact as a MacGuffin to have conversations that need to happen. It’s a little bit like the stone soup thing, right? The story about the stone soup that I’m sure people have heard. We’ve gone from having a bunch of basically stones to get important conversations to happen to now having the equivalent of the Star Trek replicator where you say, “Just give me chicken soup,” and you get the plate of chicken soup, but then you don’t get the collaboration that happens in making the soup, right? That collaboration is really important.

Greg: Just to build on that, I think one of the risks that we have is that we spend our day collaborating with AI and not with each other. It’s very easy to do. It came up in one of the workshops I recently led that folks were in a product team spending less time talking with each other and more giving each other things to read. Not all the things that they were giving each other were as tuned as they could have been, but they felt very clear to the person who had been participating with their AI assistant. I think we are at risk of finding our way into that relationship with the AI versus finding our way into a relationship with the cross-functional peers that we work with. Again, it goes back to the healthy boundaries. I think we need to find how we manage that, and I have anxiety around that because I spend a lot of time with these things. I think there was another piece of the story that we wanted to talk about today. There was an article that I really loved, and I excerpted part of it last week, and a lot of people responded to it by Hepburn on going fast and how this was a moment for generalists to be really successful. I felt seen in that article, and at the same time, I recognized that maybe it was a little bit of wishful thinking on my part. I think we’re all guilty of finding the things that reflect well on our own personal point of view that reinforce our vision of ourselves. There was a piece in that about moving fast—not about velocity, but it was more about, you know, one of the things I think we’re in this moment is, some people are using the tools effectively, and they’re using them with their teams and gaining a certain sense of momentum. They’re being intentional about it, learning how to do it, and course correcting. Others are not, and I think there’s some anxiety around that too because some organizations don’t enable teams to do that. Are you feeling like you’re left behind? I think for my own self, I have anxiety around keeping up. I know there are people who are way more into this than I am, and so therefore my keeping up is a worry.

Jorge: The article you’re referring to is a Substack post called “Welcome to the Intelligence Era” by Hepburn. What I’m going to do is, when we release a recording of this, I’m going to add links to these various posts in the description for the video. The metaphor Hepburn uses for this speed thing is learning to ride a bicycle. He makes a good point that one of the risks you run when learning to ride a bicycle is that you try to take it too slow. If you’ve ridden a bicycle before, you know that it’s not until you reach a certain speed that you can maintain your balance. He’s advocating for getting up to a certain speed to get your bearings. He doesn’t say this in the article, but there’s a flip side to this: if you’re learning to ride a bicycle and you strap a jet engine to the bicycle, you’re going to be really stressed out, right? You’re probably going to get in an accident. I think there’s a Goldilocks thing here; I’m trying to reflect back what’s emerging from this conversation. You’ve already said we need smaller teams that have greater agency. It also sounds like they need to focus; they need to prioritize the stuff that they’re working on. There’s the notion of speed—meaning they need to move fast. Maybe the phrase is they need to move fast enough, but it’s possible to move too fast. The organization, the team, the individuals might not be able to handle being asked to do so much so fast with such new stuff because, to your point earlier, there’s cognitive load involved.

Greg: Yeah, I think the velocity conversation has many vectors to it, too, some of which are super anxiety-producing. You hear a lot of leadership in the Valley right now talking about speed and how fast we have to deliver product outcomes. Now that Claude can write most of the code, we can go 10 times faster. I don’t think that’s necessarily what we’re talking about. By the way, I think there’s a huge risk in going faster; it doesn’t necessarily mean that you get to a good outcome. At the same time, I think what Hepburn is talking about is you need to dive into understanding how these tools work because they are changing the way that we work and, for each of us, they’re changing who we are and the roles that we have and the impact we can make. We can push back on it if it’s going too fast, but you really don’t learn how to use them unless you’re using them. The advice I have for folks is to get your hands into it and be using it. Then you can be intentional about how you want to use it. One of the opportunities I think in this space now is that especially in product development, a lot of time was spent on execution and not enough time on defining the outcome or the product fit. Now, I think we can use these tools to do a lot more discovery earlier and have more clarity about what problem we’re trying to solve, why that problem is valuable to the end customer or end user, and get validation that we’re solving the right problem. Execution—building that piece—should be something that can go much faster. This inverts how we look at the work that we do, and that part of it is exciting to me. But it’s different.

Jorge: I want to maybe pinch and zoom into the word invert. But before we do that, I want to circle back to the chat. We have a couple of comments in the chat, and I think the first one here is relevant to what you’re just talking about now. So RPUXD671 says, “I agree. We can’t be too precious. Yes, and we need to show up with calm and help the teams we’re advising through trade-offs they face.” Here’s the question: how do you hang on to and transmit that calm through teams?

Greg: Yeah, that’s right. I think a couple of things are important. One is being curious, right? Having a culture of curiosity, being conscious that you don’t know the answer, and being public about it. One of the challenges is when we think we know the answer, and then it pivots and changes—it just undermines team health. It’s a notion that we’re on a collective journey together, and we’re going to explore and find out where we’re headed. Those are some things I would consider. I think there needs to be—you said this earlier around how to prioritize the efforts you have because you can go everywhere all at once and not get anywhere. Practice some exercises around what are the experiments you’re going to do as an organization or as a team and create some space for evaluating the success of those experiments. This is something you and I did with one of our customers last fall, where we sat and kind of helped them understand how they worked, looked at the activities and workflows that were important to their success, and helped them stack rank the things that we felt AI could help them with. Instead of doing all of them, we said, “Let’s pick one and do that.” How did that work? Did we learn something? Okay, let’s go do the next one. I think a structured approach could help teams have a little bit more comfort.

Jorge: I think this question was framed around how do you, as a leader, communicate with your team? That’s the way I read it anyway. But I think what you’re saying also applies to how do you manage up, right? Because as a chief design officer, as a VP of design or product, you are reporting into the organization’s leadership. They have expectations—whether fair or not—that this stuff is going to change things quickly, right? It’s worth acknowledging that leaders need to manage their teams and the mood of their teams, but they also need to manage upwards, right?

Greg: Yeah, and there have been all kinds of crazy statements made in the last two years around the possibilities, role definition, and how product is going to be made based on the lens of where a leader might come from. I think we’re learning right now that those lenses are incomplete. You bring up a really important point; this curiosity and openness and adaptability need to be shared when you manage a team down or when you’re working with people collectively. It also needs to be flipped on the opposite conversation: what are we learning right now? What advantages is this giving us, and what challenges are we creating? There are challenges being created. Many teams are spending a lot of effort on AI, but their productivity isn’t improving. Many teams are spending a lot of tokens, but their costs are going up in the organization. Some organizations are letting people go because they think AI will fill the gap, but they’re letting them go before they figured out how to do that work. Those are the things that I think are building anxiety right now. The sad part is that we’re having the wrong conversation. People are talking about, “Here’s our current business model; here’s how we work, and now we can just do it faster and more simply.” The conversation I want to have in organizations is, “Here’s the community of people we serve. Here’s how we can deliver better outcomes for them. Here’s how we can grow our business, and here are the new things we can do with the people that we have that are valuable to that constituency.” I just don’t think we talk about that enough.

Jorge: We have another comment here. It’s not a question, but it’s a comment from Albie underscore G. They say, “I agree with Greg. Without intention, it’s easy to lose control of the output. Planning and guardrails are essential.” I will chime in here and say, even though your name is checked in this comment, I want to point out that when you talked about smaller teams, you did not use the word control; you used the word agency. That is an important distinction. As I hope is becoming evident from this conversation, one of the footballs that is being tossed around the field right now is precisely control—control over the outputs, control over the process—which is part of why there’s this anxiety happening. I think it’s going to be important to live with the—I’m going to use the word—discomfort that comes from not feeling like you have full control over the output. What you want, I don’t think that you want control; I think you want agency. That’s my take anyway.

Greg: My personal belief is that teams do better when folks have agency. I’ve always tried to build organizations where there’s clarity, and the gift you’re giving is, “Here’s where we’re trying to go. You figure out how to get there.” I do think where I’ve seen AI being used well is in groups that are willing to experiment and communicate and not try to own or control the process of how it works. Instead, they have a conversation with each other about how it’s impacting the way that they’re operating and how the outcomes for which they are responsible are improving or not improving by using the tools. That’s the part that I think is fascinating. My hope is that we’re responsible about it, and we have these conversations, but it’s not easy, and sometimes we don’t have the frameworks to have those conversations. I think you and I have talked a lot about this, and it’s part of what we’re trying to do here with Unfinishe: help people have healthy conversations around how they can use these tools in their environments and provide some structure that allows them to make progress.

Jorge: That makes a lot of sense. We have only about nine minutes left here. If folks who are viewing have any questions or comments, please do post them in the chat. Greg and I want to have conversations about this. We have been monitoring what people are writing, but we are also having conversations one-on-one with folks in organizations. If you want to talk with us, we would love to meet up to compare notes and have a quick meeting. I’m flashing on the screen a URL that you can go to set up time; we’d love to hear from you. If you are watching this now and have any questions, please do post them in the chat. Let’s start rounding the bend here. We are running out of time. Our intent here, as we said at the top of the hour, was not to offer a very structured conversation; this is really kind of thinking out loud. It does seem to me that there are a few points that are worth noting. The first is acknowledging that we are in a time of anxiety, and I keep tying this time to the early part of the web when the web first came out. That was a time of big disruption, a big new technology; it was clear to many of us that it was going to change things much like it is now. I don’t remember there being this level of anxiety of, “It’s going to replace my…” I mean, there are a few people who saw the writing on the wall that I wouldn’t be making any more printed financial reports for organizations because all that stuff is becoming digitized. That was pretty clear. For the most part, there wasn’t the level of replacement anxiety that we’re feeling now. It does feel like there is angst, and there’s an HBR article that I’ll include in the description that names it “AI Angst” and outlines what that means and why it might be caused.

Greg: I would just build on that. This is a moment where our identity is challenged. Each of us, no matter what you do, has made decisions in your life and constructed a story around your expertise. That is part of who you are. This moment can feel very unsettling because a lot of that narrative can be challenged. How do we manage through that? I think about this moment personally—I used to lead large teams, and my identity was a chief design officer. Now I’m not doing that anymore. Now I’m helping organizations as a fractional leader. I come in and support teams and do some work. You and I are doing this work for helping organizations prioritize. I’m coming to terms with that: what does the new version of me look like moving forward with these capabilities and tools? It’s not the chief design officer that I used to be. That’s unsettling. I spent a whole lifetime building that narrative. I have adult kids, and I have curiosity about how that happens. The attitude you have to have is to be curious, mindful, and intentional. I don’t know. What are you anxious about in these final moments?

Jorge: I’m smiling because this hits so close to me. I’ve been calling myself an information architect for almost three decades at this point. Information architecture is so deeply part of my identity. A few days ago, someone posted on LinkedIn saying, “Oh, I had a conversation with someone who was talking about getting into information architecture.” They asked where to begin, and I said, “Look at this person’s work. Look at this person’s work.” There were three references, and the third was me. It stated something like, “Look at Jorge’s website, but he’s more focused on AI and LLMs these days than information architecture.” I felt like, is that true? I immediately wrote back and said, “It is true that a lot of my efforts have been focused in this direction, but I don’t see it as a replacement of my identity. To me, it’s the contrary. I don’t think you can be an information architect and not be all over this stuff, because it’s so obviously important.” The way that I put it on my website is that information architecture changes as a result of AI, and AI is made better as a result of information architecture. With all these SaaS replacement narratives from the mainstream media, my canned retort is that information architecture is your moat. You can’t just replace a system that has a lot of carefully structured information; it’s not going to be replaced by a chatbot with no context. I’m seeing an evolution of my identity rather than a replacement of it, so I don’t feel as much anxiety there. Where I do feel anxiety is the question of, how do I make a living doing this? Because, to your point, if nothing else, the perception out there is that now that we have these tools, they can structure information for you. Yes, but there are a bunch of asterisks following that. My last three years have been about investigating those asterisks. I think that’s going to be true for a lot of knowledge work. That’s a big part of the anxiety here: the narratives out there say you’re going to be out of a job. I’m not entirely sold on that, because I think these are tools that will definitely change the work, but they still need expertise to produce really good results. That’s where I stand right now on that stuff.

Greg: I love that. I think this goes into, you are on the bicycle or not, like we talked about earlier. I think there are some things that, I don’t know if it will happen, but if the cost to deliver a software outcome reduces significantly which is where we’re headed—the amount of engineering required, the tooling that allows you to deploy something is lowering—does that mean less work for all of us? Or does it just mean that there’s a whole set of new use cases that were too expensive to solve before are now solvable? I don’t know that the equilibrium around that will be. My hope is that we’re intentional about the problems we’re trying to solve in this world and that these tools allow us to solve more of them. I think you’re right: the architecture of intelligence, the organization of the information, and the organization toward the outcomes that matter will be a skill set that’s really important in the future. Not everyone will gravitate towards that, but I think folks like you will be very valuable. You are very valuable.

Jorge: Thank you. You are very valuable too, Greg. We are out of time. I just want to acknowledge there are a couple of comments in the chat we can get to after we release the recording, but there’s one comment that speaks to this from RPUXD671 again: “It’s not going to be replaced, well, by a chatbot, but some organizations will try.” I’ll say this: we are living through the very early days of this, and there are going to be all sorts of really poor decisions made. We’re going to try all sorts of things that are not going to work, and we just have to go through it. This is the bicycle thing: you have to keep going, and you have to find stability. We are out of time, unfortunately. It’s been brilliant catching up as always. Thank you.

Greg: Awesome. Thank you all for joining us today. We’ll try another one of these soon.

Jorge: I’ve flashed the slide on the screen. If you want to set up time to talk with us, please visit unfinishe.com/connect, and you can set up some time. All right. Thank you, sir.

Greg: Thanks, Jorge. See you soon. Bye.

Recently, I had a conversation with an architecture studio lead that went something like this:

Architect: We’re using AI in the studio.

Me: Oh yeah? What are you doing?

Architect: A few things. [Person A] is using one of those meeting bots to transcribe meetings. And [Person B] is feeding renderings into ChatGPT to explore materials and colors. Clients are impressed.

Me: Interesting. Anything else?

Architect: Yes, [Person C] has used ChatGPT to create social media posts. Although we haven’t really scaled that.

This is actually a composite of several similar conversations, and I’ve changed the details — but the spirit stands. I believe this short dialog accurately represents how many service organizations are embracing AI: by dabbling.

Dabbling — or, more gently, “undisciplined adoption” — is experimenting with AI without understanding how information actually flows through the organization to create value. Instead, team members use AI ad-hoc on whatever interests them most. It can happen officially (i.e., using company-provided licenses) or unofficially (bringing their own.)

While dabbling has upsides, it also carries significant risks. It also precludes getting the most value out of AI. Let’s explore how.

Upsides of Dabbling

I can think of at least three pros to dabbling with AI:

• Quick learning. By now, most folks in service industries have heard about AI. Many are wondering how it might help their business. But reading about a technology isn’t the same as using it. Dabbling gets them rolling quickly: Setting up an account is easy, and getting a useful reply to a prompt highly satisfying. A nudge to go deeper — good!

• Low friction. Basic LLM accounts are free and the pro versions around $20/month — not a big commitment. A ChatGPT account and YouTube will get you rolling. No need for big culture change initiatives, reorgs, or IT investments. And unless your IT department put the kibosh on it, you won’t be stepping on anyone’s toes.

• Nice spread. AI is a general purpose technology: it can help with research, production, marketing, finance, etc. With different people experimenting, as in the example above, you’ll get glimmers of possible applications. Letting a thousand (or, more likely, half a dozen) flowers bloom will give you a sense of what the garden might include.

Given these “pros,” it’s understandable why firms dabble: it’s a nonthreatening way to get started on the journey.

But It’s Not All Roses

Dabbling is better than nothing. But it has significant downsides:

• No governance. Let’s start with the scariest. Undisciplined AI use is a privacy and security risk. Unless you have a properly configured pro account, your chats will likely be used to train models. Meaning, your private data might show up as an answer to someone else’s prompt. There are good reasons why your IT team wants visibility and control!

• Learnings don’t scale. Yes, dabbling lets team members get into AI. But that learning won’t be evenly distributed. And their focus will be on narrow problems (e.g., crafting a social media post, tweaking a rendering) that can’t be leveraged more broadly. They’ll likely have no plans or means to feed data back into the org’s broader data repositories.

• Wrong mental model. Fast learning doesn’t mean good learning. By dabbling, team members will come to understand AIs as freestanding tools whose abilities reside in vendors’ clouds. They’ll assume utility lies in the chatbot’s cleverness rather than how they leverage structured information. This is a bad mental model. AIs should be understood as adding smarts to (and with) their firm’s IT infrastructure.

• Opportunity cost. By focusing on “paper cut” problems, org leaders can boast that the company is already “using AI.” As a result, they’ll fail to invest in projects that have greater upside potential — something that can only happen when they consider initiatives as holistic responses to strategic directions. By dabbling, the org gets a false sense of closure while leaving lots of value on the table.

What To Do Instead

Ok, so dabbling isn’t a good strategy. But that doesn’t mean you shouldn’t use AI at all. So how should you proceed instead?

1. Identify your business’s “soul”

Start where your organization shines. What makes it stand out from competitors? What’s the secret sauce? Where does it create most value? Don’t threaten those things. Instead, look to automate the chores that keep you from delivering your particular kind of value in a timely and cost-effective manner.

2. Define your knowledge pipeline

And how do you do that? To begin with, you must grok the organization’s “knowledge pipeline” — how information is created, transformed, passed on, searched, used, etc. All businesses generate and consume data: leads, proposals, research, responses, invoices, documentation, etc. The more structured this data, the easier it’ll be to integrate into AI-powered workflows.

3. Understand AI’s real capabilities

Many people are pushing unrealistic ideas of what AI can do. The reality is that while LLMs are a powerful general-purpose technology, you can’t just point them to a problem and say “fix this” — at least not in a scalable, and repeatable way. Understanding what the technology can do today is essential to designing systems that create real value consistently, rather than one-off automations.

By mapping how information flows through the organization, where the real value lies, and what AI can (and can’t) do well, you can determine how it might best alleviate information bottlenecks — without threatening your people.

A Real-world Example

Recently, Greg and I helped an architecture studio define a coherent direction for their AI use. Outlining the studio’s knowledge pipeline led to an interesting discovery: a significant portion of their time was spent responding to questions during the construction administration (CA) phase of projects.

Given current LLM capabilities, we determined that helping build CA dossiers would be a good place to start. It’s a time-consuming task that few people want to do, but which must be done to deliver value. But it’s also far enough removed from the studio’s core deliverable — excellent architectural design — that it doesn’t threaten their soul.

This isn’t the “sexiest” use of AI, the sort one brags about. But it solves a real problem in a scalable and repeatable way. It enhances the overall value to clients and improves working conditions for team members. It’s a win-win all around — but you don’t get there by dabbling.

Moving Ahead — With Discipline

Dabbling isn’t dangerous just because it’s uncontrolled. It’s dangerous because it gives the firm a false sense of progress. It teaches people to think about AI in the wrong way — as a clever ad hoc tool rather than as part of a broader system — while distracting them from more fruitful explorations.

The opposite of dabbling isn’t stasis; it’s moving ahead in a disciplined way. Starting undirected is natural and easy. But eventually, you must move more deliberately and strategically. The goal of using AI shouldn’t be replacing what makes you special. Instead, it should be freeing your people so they can deliver excellence — and enjoy the process.

If this resonates, unfinishe can help. We work with small and medium-sized service firms to move beyond AI dabbling and deliver real value.

Jim Moylan died recently. He was the Ford engineer who proposed that little arrow on the fuel gauge of most cars that indicates the cap’s location. It’s handy when you’re pulling into a gas station to refuel, especially when you’re driving an unfamiliar car.

The Moylan arrow is such an obviously useful idea that it was immediately implemented by Ford and widely adopted by other manufacturers. It’s also an excellent example of good information architecture — and one that provides important lessons as we navigate the AI age.

How Is This Information Architecture?

Information allows us to act more skillfully. Imagine you come to a fork on a road. Without a sign, you’d need a compass or a great sense of direction to choose correctly. But with a clear sign, you’d quickly know which road to take. The sign reduces ambiguity.

The Moylan arrow, too, disambiguates a choice. Pulling in on the wrong side of the pump is an annoying inconvenience. By making the driver smarter, the arrow improves the car’s UX. Critically, it does so without much cost to the manufacturer. That’s why it’s become pervasive.

“But,” you may protest, “this isn’t IA; it’s user interface/icon design.” That’s partly true. As usual, users experience IA in an interface. The arrow wouldn’t be as effective if it wasn’t clear and recognizable. Visuals — the choice of symbols (an abstracted gas pump and a triangle) and colors (usually white on black) — are key.

But there’s more to it than that. A big part of the arrow’s effectiveness is its location: on the dashboard, next to the fuel gauge — exactly where you’re looking when your car needs refueling. Consider how much less effective it’d be if it were only noted in the owner’s manual.

The Moylan arrow works because it’s:

• Clear: legible and understandable

• Findable: located where you’re already looking

• Relevant: provides the exact answer you need

• Contextual: available when needed, but “quiet” otherwise

• Obvious: doesn’t need further instructions

• Cheap: of negligible cost to manufacturers

The arrow isn’t just a clear icon. It disambiguates a key structural distinction of the car. The mental model is clear: most current ICE cars have their fuel cap on either the left or right side. The question is, “which is it for this car?” The answer is obvious once you know where to look — and it’s cognitively respectful (i.e., it doesn’t scream, “LOOK AT ME!” while you’re driving.)

Which is to say, the Moylan arrow:

1. answers a latent question (“Which side is the fuel cap on?”)

2. at a time when the user is making a key decision (pulling in to a gas station)

3. by showing them just what they need (left or right side)

4. where they expect to find it (on the dashboard, next to the fuel gauge)

5. cheaply, efficiently, and respectfully.

That’s classic information architecture.

What Does This Have to do With AI?

This is the opposite approach to many of today’s AI-powered systems. The arrow is low tech (just a bit more paint/pixels!) and therefore relatively cheap. It does just one job — resolving structural ambiguity — effectively and efficiently. It’s there when needed and blends into the background otherwise.

Admittedly, its elegance is due in great part to the binary, static, and universal nature of the information it conveys. The cap can only be in one of two positions: left or right. These concepts are unambiguously represented with arrows across cultures. (The pump is more complicated but still recognizable.) Also, the information is static: the cap won’t change sides between fuelings.

This is a very constrained set of requirements. But compare Moylan’s solution with many AI products today, especially those with chat interfaces. Rather than a constrained structure within an expectable construct (dashboard → fuel gauge → [left|right] arrow), chats offer completely open-ended interfaces. This may be appropriate for systems that require extraordinary flexibility, but it’s overkill otherwise. And while flexibility adds power, it opens the door to complexity and errors. (Consider the risk of hallucinations!)

Chat interfaces also have higher latency than more structured UIs. Conversational interfaces require explicit instructions — either spoken or typed — before they can provide utility, and getting there may take multiple rounds. To put it bluntly: for many tasks, chat UIs are inefficient. Compare this with the low latency inherent in Moylan’s “ambient” approach: just glance and turn the wheel.

Finally, many AI-powered products call too much attention to themselves. The value to the user (e.g., avoiding the inconvenience/embarrassment of pulling in to the wrong side of the pump) takes a back seat (sorry!) to the fact the product now “has AI.” Lacking good system models, users can only guess at what pressing the pervasive “sparklies” and “copilot” buttons might do. Many users recoil when products add complexity through seemingly gratuitous features.

What Can We Learn From This?

I’m not poo-pooing chat UIs. They’re appropriate for some use cases. But they’re also overused. I expect this is because of two reasons:

• Chat = AI. Many people associate chat UIs with AI, so they expect conversational interactions.

• Laziness. It’s easier to graft a chatbot onto a product than redesign its IA to accommodate new capabilities.

Both reasons are bad. If you believe your system’s value will come from making it more “intelligent,” it’ll likely turn out overwrought. Users get most value from systems that help them effectively and efficiently and otherwise get out of the way. They don’t want to “AI all the things”; they just want the right information when and where they need it. Everything else is noise.

Rather than ask, “how might we add AI to this system?,” consider the following questions:

• What is the person trying to do?

• Do they understand the system?

• What’s keeping them from choosing skillfully?

• What questions do they have? Which come up repeatedly?

• Which structural distinctions are ambiguous?

These are information architecture questions. AI might play an important role in answering them — even in real time, as the user interacts with the system. But it won’t happen by simply “adding AI.” Instead, you must understand the user’s needs as they work with the system. Then, you can determine where to judiciously apply AI.

Also, rather than an open-ended UI (such as a chat,) consider whether your system might be better served by a UI that offers clear distinctions and affordances. Buttons and menus don’t just give users means to act: they also help them understand the system. A thoughtful IA will make your AI-powered product easier to use — and likely do it more cheaply and elegantly than a chat UI.

Closing Thoughts

I doubt Jim Moylan thought of himself as an IA. But that doesn’t matter. We can study manifestations of an area of practice retrospectively even if they weren’t explicitly produced as such. (For example, we think of many ancient buildings as “architecture” even though their designers didn’t think of themselves as architects in our current sense.)

As the practice of designing AI-powered systems matures, I expect we’ll move away from general-purpose interfaces to systems that use AI on the back end while presenting a more traditional UX. There’s room for delight and intelligence in simple, less open-ended systems. The Moylan arrow is an excellent example.

In the spirit of working with the garage door open, we’ll do periodic livestreams to share what we’re learning at unfinishe_.

In this first “Open-Ended” session, we discussed:

1. The principles that led us to start the business.

2. Insights from Reid Hoffman’s and Greg Beato’s new book Superagency — especially as they apply to small and medium sized businesses.

3. Workflow archaeology, our approach to designing solutions that are aligned from both a strategic and human perspective.

We’d love to know what you think.

Transcript

(AI generated.)

Jorge: All right, Greg. Good morning, sir.

Greg: Yeah, good morning. Well, it’s good to see you live streamed.

Jorge: I’m excited, yeah, same here, and just before we jumped on, we were having a bit of a fingernail-biting moment trying to get everything set up right. We’re very much figuring it out as we go. But we are doing what I think are interesting things, and we were hoping to share with folks. And this seems like an easy way to do it. Do you want to explain a bit about what this is all about?

Greg: Yeah, thank you for setting it up nicely and actually talking about how this is an unfinished moment in and of itself. Jorge and I have known each other for a long time, and we’ve worked together at moments. And we’re both really fascinated by where we are right now—the culture and the implementation of technology and AI. I think we both feel like a lot of the things that we’ve learned in the past aren’t really applicable in this new environment, and that we have to learn new things. At some level, learning those new things means disrupting ourselves and examining practices that we’ve held dear over the last 20 years in our careers and seeing if they’re still valid, and then also exploring the territory that’s available in this new space. Right? And I think we started that conversation and decided, hey, let’s put something together. And so we started this thing we’re calling Unfinishe. The D is missing on purpose. It tells a story about, I think, the market, the space, and the place that we find ourselves in. I don’t know, maybe you could talk a little bit more about your… I’m taking some airtime here, so you jump in and talk a little bit about what you think Unfinishe is.

Jorge: Well, I just wanted to touch on something you said. I think you said that the things we learned in the past aren’t applicable. Is that what you said?

Greg: I said that we need to re-examine. I did, but I think what I really meant was we need to examine whether they are still applicable.

Jorge: Right, right. Well, the reason I started there is because there’s a flip side to that, which is that as disruptive as the current moment feels—and we’re talking specifically about AI, right? Like, there is a new major technology that is upending a lot of things. And as disruptive as this moment feels, both you and I have been through another disruptive moment like this, which was the dot-com era, you know, the appearance of the World Wide Web in particular. Right? That was a major, major thing. And we now kind of take it for granted because it’s become so pervasive in our world. But I remember going through that time when design was up in the air, and publishing was up in the air, and there were all these things where it’s like, well, this needs to be reinvented clearly because we have this different thing happening. In retrospect, it feels like, well, of course that’s how it would turn out, but it wasn’t obvious at the time. And it entailed a lot of experimentation. And part of the reason why, circling back to Unfinishe and the concept of making things that are unfinished, is I think that we have this drive for closure. We want things to be neatly wrapped up. But in times of transformational change like we’re going through now, we don’t really know how things are going to turn out. We don’t really understand the technology’s implications yet. We’re in the process of discovering that. And one of the things that I learned—and maybe you can chime in on your experience—but one of the things that I learned from the previous wave of disruption that I was part of was that you can have these big ideas about how technology is going to transform things. You can have ideals about how it should transform things. But the changes actually happen more incrementally through a bottom-up approach with people trying things, seeing what sticks, and then that is what affects the transformation.

Greg: So, yeah, it’s a maker-builder mindset, right? You know, I oftentimes talk about how some people think to make, and others make to think. I think we’re both makers. One of the things that’s interesting about this space is it’s emergent, right? There’s a conversation going on. It’s really fast. So I think that’s one of the things that’s a little bit different. I don’t know if the dot-com era moved fast, but this era is moving super fast because every week there’s some new model, capability, discovery, or insight. So it’s challenging. I actually think that’s one of the things that we’re thinking about with Unfinishe; it’s also helping organizations make sense of the moment by making practical things. Our insight is that we’re not suggesting that we’re super experts in this space, but what we are saying is that maybe we’re eight weeks ahead of you. We can help be a little bit of a Rosetta Stone or a wayfinder for organizations around how to understand how to use these tools and think about it in a really practical way. I think that’s the basis behind why we think Unfinishe as a consulting practice is actually valuable and necessary right now. In the space that we’re looking at—which is small and medium businesses—and this is something we should also talk a little bit about: why are we looking at the SMB space? There are a whole bunch of opportunities to help organizations punch above their weight, to help them manage some of their complexity more effectively so that they can focus their attention and energy on the things they really love or growing their business in a way that makes sense to them. Some of these tools do give you some superpowers. So how can we help organizations make sense of which ones to use and which outcomes are more applicable now and are most useful? I think that is a journey that we want to help people on. Just back to why we’re calling ourselves Unfinishe. I think one of the things that business leaders have to recognize in this moment is that you are either evolving or you’re not, and that transformation is something that you need to continuously invest in and have a mindset around. Your point earlier that you talked about closure or completion or having it all figured out— I think the ethos now is to dive in, experiment, make, find your way, and keep on that path while recognizing that you need to keep moving forward.

Jorge: I love that you use the word evolve. I will draw a distinction between evolving and reinventing. Because so much of what one reads out there—when people write about AI—and I’ve seen this with a lot of other consultancies, it’s like the pitch is, you need to reinvent your business for the AI age. I think our approach is more, “You know what? That sounds like premature optimization for a world we don’t really understand yet.” It’s much better to try these very carefully defined, pragmatic experiments that help you make steps towards an alternative future, as opposed to this whole huge initiative where it’s like, let’s reinvent everything and rethink everything from the ground up. All right. Let’s not belabor Unfinishe itself. We’ll have more opportunities in the future to talk about what we’re doing in the business. We’re talking about Superagency. This is a book that I had not read. You suggested this book, and I was hoping that you could talk a bit about why Superagency? Why this book? And what is this idea about?

Greg: Yeah, I mean, I think it’s one of the pieces of content this year that tries to unpack where we are in this moment. Hoffman’s book has a couple of tenets in it that I like. One, he talks about technological transformations historically and sort of recognizes the societal disruption and the ramifications of that in those moments to give us a compass for what’s happening right now. What do I mean by that? He talks about the invention of the steam engine, the reaction to industrialization in the Luddite movement. He has a kind of model for a two-by-two of different characteristics of people who have a point of view about where AI is from, you know, when he calls it doomers who believe it’s the end of everything and, you know, the zoomers who are like, “No regulation, no AI at all costs,” etc. And that framework, I think, starts to establish, you know, and then there’s bloomers and gloomers, right? So there’s the four quadrants. I tend to see myself as a bloomer, but that’s because I’m an optimist, and I believe that we get to choose the future we want to live if we’re intentional about how we operate. I think this is one of the things that’s very important, actually, about right now—that we need to be looking at these tools in a really smart way and make sure that humans are in the center of the conversation. The last tenet in his book is around agency, and that these systems should enable us to have agency—that we get to make decisions, that we get to make choices, that we get to use them for things we think are valuable. Obviously, there’ll be some disruption in employment, for sure, but there’ll be new opportunities that emerge out of this technological change as well. That’s why I thought the book was interesting—because it was trying to put this into a context of, “We’re in a messy moment. The way out of that is to actually be intentional about doing things that have a positive impact.”

Jorge: You talked about the four profiles. And I think the way they—it’s two authors, Hoffman and Beato—but I think of this as Hoffman’s book in some ways, right? They talk about these four profiles as people who are part of the conversation. They say these are voices that need to be in the room—you have to accommodate that discussion. You said that you associate or think of yourself more as a bloomer. When I read the book, I too thought, “Totally, I’m a bloomer.” People watching this might not have read the book. Could you give a brief outline of the bloomer profile? And while you’re thinking about that, I’ll say we do have people tuning in. I’ll just put it out there. This series is called Open-Ended Sessions. The idea is to make this a conversation because it’s unfinished, right? So if you, who are tuning in, have any questions for us or any comments, please drop them in the session chat. All right, Greg.

Greg: Yeah, so bloomers, right? I think bloomers are optimists. They believe in progress, and they believe there are opportunities that can be created by the emergence of new technology, identifying opportunities to use that for positive outcomes. I feel like that is my mindset. I’m not unaware of some of the challenges and issues and problems that are materializing because of this change or this moment we’re in—the environmental consequences of building data centers, the background of how the content has been created. But I feel for me—and one of the reasons why I think I want this partnership you and I are putting together—is to be intentional about helping organizations make the choices that make sense for them and allow them to be successful and do it in a way that’s human and places humans in the center of the conversation. That’s the kind of work that I want to do. I think the bloomer category is someone who believes that the long-term impact of this is actually going to be good for society. It may be rough in the beginning, but there are positive outcomes to be had. But it means that we have to put in the effort and the energy to make sure that that happens.

Jorge: The phrase that kept coming to my mind when I was reading the book is this is a glass-half-full mindset. But that doesn’t mean—it’s an optimistic approach, right?—that doesn’t mean a Pollyanna approach. To your point, there’s a recognition that this is a very powerful technology, and like all powerful technologies, they need to be deployed mindfully. Now, the devil is in the details, right? The question is, what does that mean? They get into a bunch of things about regulation in the book, which I don’t think we’re going to touch on here. But you mentioned when you were introducing the work that we’re doing that we have decided to focus our offerings toward small and medium businesses.

Greg: Yeah.

Jorge: I’m curious about this idea of superagency and what it might mean for small and medium businesses. I have ideas about that, but I’d love to hear your take on what those are.

Greg: Yeah, I mean, I think one of the things that’s interesting is that small teams can do more things in a way, right? That’s evidenced by some of our work. If you think about, you know, one of our more recent engagements, we discovered that an organization we were helping was spending a significant amount of time doing administrative tasks to fulfill legal requirements and compliance requirements for their work. We’re talking vaguely because they just don’t want to say who it is or what they’re up to. That number was increasing over time, hitting their margins, and they didn’t really understand what was going on. At a certain level, it was sort of like they were like a frog in water—turning up the heat, they’re getting boiled by more and more content they had to manage. This was preventing them from doing the things they wanted to do, the things they valued, and the things they felt differentiated them in their marketplace. One of the things we did was work with them to try to understand how they operated. From that, we discerned what might be simple, small, practical things that they could automate or use AI to assist so that they could focus their attention on things of high value to them. That’s an allegory for what we can help small and medium businesses with. You said it right: no one loves to do the laundry. Some people do, but most people don’t like to do the laundry. So let’s help you do your laundry so you can focus on what’s truly important to you. We can talk a little bit about how we’re doing that. The second thing is small and medium businesses are much more willing to try things and experiment. You don’t have the layers of bureaucracy that might hinder a larger organization around what you can and can’t do. The opportunity for innovation could be higher.

Jorge: I want to be fair; the laundry analogy comes from—I’m not sure how to pronounce her surname—but Joanna Maciejewska. I must be butchering that. She put out a tweet saying that the problem with AI was directionality—we’re trying to automate the wrong things. We’ve been automating writing and creating art. What we want is for AI to automate doing the dishes and the laundry so that we can focus on writing and creating art. I think that’s fundamentally right. I think it’s also more… It feels to me correct regarding the state of the technology itself.

Greg: Yeah, I agree with you there, too. Is it ready for all of this agent-to-agent conversation stuff that’s going on? I don’t think so. Maybe at some point in the future, but what we found in the engagement I was just talking about is that, in the abstract, technology alone isn’t something that will land in an organization. You need to understand the culture of the organization, how people work, their mental models, and the flow of information. We came up with this term; we call it workflow archaeology. It’s a bit different than service design practice or the UX space we’ve come from because it requires some additional investigation, but it leverages that skill set. It’s understanding the journey from start to finish of an outcome or a job—something valuable for an organization. Then you have to dig in and see how that happens. You need to understand the information flow, the shape of the data, where it’s stored, and how it’s managed. You also need to understand how people expect it to show up on their desktop or in any way they work, and then you can affect change. You can add a small intervention or a small evolution— I like the word evolution versus reinvention. Evolution enables a performance gain or improvement or unlocks some extra capability they’ve always wanted to do but haven’t been able to do before. You do that incrementally. This moment isn’t calling for us to blow up the firm and say to start over; it’s much more about getting you up to speed on one thing so that not only do you have something valuable, but you also start to understand how these things work so you, as an organization, can recognize how you want to use them and what they mean to you and what’s meaningful. In the case of the organization we supported, we delivered an outcome that led to productivity gains, but their intention wasn’t to let go of people; their intention was to spend more time on things they viewed as high value. Every organization is going to have a different calculus about what matters to them, but right now, these things have to be small; they benefit from prototyping your way of making. We talked about this maker mindset earlier. That’s part of the journey we want to help people take on—practical, straightforward things you can do that add value as quickly as possible.

Jorge: And I think that’s part of the actionable outcome of an engagement like this—the thing you can fire up Monday morning and start doing that changes your workflows and hopefully relieves people in your team from drudgery. But I think there’s another level of value that comes from these engagements, which is that they help the organization get a sense of direction.

Greg: Yeah. I think this is an important piece of the puzzle. Maybe you can talk a bit about how we do that, but this is a really important perspective because many organizations—probably most—don’t know where to start. If they are doing things, they’re often in an unintentional way. There’s a fair amount of evidence that says people are using AI, but it’s not giving them any positive outcomes; it’s just burning time as people sort of goof off or experiment with it. What’s your perspective on that? Why is that so important, and how are we doing it?

Jorge: Well, the sense I get is that there must be a sense of the emperor’s new clothes in people’s minds right now—in that you read the news and see these huge investments happening in data centers and organizations cutting human positions to invest more in AI. There must be a lot of people wondering, what is the AI doing? The experience most people have had with these tools is through chatbots like ChatGPT. What I’ve observed, and I think you’ve seen this as well in talking with folks—especially in small and medium businesses—is that there is curiosity about AI. You can’t help but be curious if you hear about it in the media and everyone is talking about it. Oftentimes, what happens is the organization’s leadership will take someone in the firm—usually from IT—and say, “Okay, you’re our AI person, figure this out for us.” What that person does is get a ChatGPT business account for the firm, give a few people in the company accounts, and then people start dabbling with trying to automate their workflows without any clear step in the process where they are provided a mental model about these tools, how they work, and how they can help. They’re also not given a holistic understanding of where these tools fit into their information workflows because it’s being done ad hoc.

Greg: Yeah.

Jorge: I think one of the tenets that is somewhat unacknowledged, but is central to the work we’re doing, is the fact that all businesses nowadays—all modern businesses, anyway—are, in some sense, information businesses. They have to move information; they have these information workflows where data moves through the organization. If you understand what the technologies can do (and you talked about us being like eight weeks ahead— I think that’s a fair assessment), the idea is to try to grip the capabilities and constraints of the tools. So that’s one aspect of this: understanding what the tools can do. Then you can gain an understanding of the organization’s information flows—how is this organization operating so you can identify areas where people are expending inordinate amounts of time and resources doing things that are necessary for operations but aren’t necessarily adding value to their customers? All companies have to deal with some degree of bureaucracy, and my emergent sense is that particularly large language models can be valuable in helping alleviate some of that tedium so people can focus their time on things that, A, add more value to their customers, and to their companies, but also that they enjoy more. No one likes having to deal with red tape. The point is that part of the value we’re trying to bring to organizations through this process of workflow archaeology is that by understanding the information flows and where the tools might help, the organization gains a new understanding of what the tools can do and a sense of direction. It’s not that we’re going to reinvent the company from day one, but at least we start developing an emergent roadmap of where the low-hanging fruit is and let’s start with a few pragmatically chosen areas to focus on, so we can begin gaining the competency internally to evolve toward that different state of being.

Greg: Yeah, and I think you bring up a couple of important points there. One, it’s a journey that we are bringing our clients on so they gain competency, right? One of the things we’ve built into our engagements is that part of what we’re doing is teaching. We’re showing you a methodology; we call it workflow archaeology, but we’re showing you a methodology for understanding how to make the tacit explicit in an organization, how to identify the IP of an organization—the things it cares about, the culture, the business processes that matter, the things that make them valuable. I think people may think in the back of their minds that many organizations—including small ones—might have a role in which someone’s only job is red tape. That’s also something to help people recognize: as these tools enable us to do more routine, repeat tasks more effectively and efficiently, you need to help your people gain and acquire new skills or focus their attention and energy on things that will benefit the business in new ways. I think we’re trying to promote is a perspective of the evolution of your organization, not revolution. The people who work with you and for you are there with you. That’s another reason why I like small and medium-sized businesses: small and medium-sized business owners are much more in relationship with their employees; many of these kinds of organizations are almost like families. If they care about what they’re trying to accomplish as a business and they care about their people, we can help them transition their organizations to take advantage of these tools while also growing their business or managing it in a way that’s meaningful for them. It’s an interesting moment to be in.

Jorge: There’s another dimension to this, which is that the information itself—if you buy into the idea that all businesses have these information flows as part of the lifeblood of the organization—the truth is that most organizations, even though that is true, probably don’t understand themselves in that light. A lot of that information is managed in a very ersatz way. It’s certainly unstructured. One of the things we are learning—and maybe we can pivot to talk about some of the lessons we’ve learned as part of this initial engagement—is that when you start working with AI, you’re going to have an easier time if the information you’re working with is structured. And hey, guess what? AI can help you do a first pass at structuring the information. I’m mentioning that because I talked earlier about our being eight weeks ahead as one of our differentiators. I think another one of our differentiators, frankly, is that we come at this problem space from the perspective of information architecture and this designerly approach of understanding how information is structured. The idea is like you were saying: to augment your people so they can create more value and enjoy their work more, as well. One way that happens is not just understanding the flow of information but also the state of the information and doing something about it. That might be that the doing something might have nothing to do with AI; it might be that you discover that your information systems are not up to speed to work with AI. You might need to upgrade those. What ends up happening, maybe, is that the AI thing ends up being a MacGuffin for this broader transformation that probably needed to happen anyway. This is just kind of the reason to get it done.

Greg: Yeah, and I think you’re bringing up an important point: that’s why we don’t call it workflow anthropology. I think we both have a design and research background, and we certainly want to research and understand how people work and see them at work. But the reason we’re calling it archaeology is that there’s this new element: the structure of the data in the environment we’re working with. Small businesses tend to not even understand that; they just build it incrementally over time, connecting different technologies, using different stuff. It becomes how they work. You need to be able to unpack it and see how the humans in the system use it; that might be the more anthropological or research lens. But you also need to see the structure of that information and its compatibility for large language models to make sense of it. You hinted that there might be some work to do organizing it more successfully so you can get better accuracy or make it machine-readable. It’s almost like there are layers to the organization that you have to appeal to in this new moment—some of service design, some user research, a bit about spelunking into the technological platforms that organizations use. It’s looking at the files— the artifacts they have— and seeing how they’re formed and shaped and the degree of variety or variation that exists in them. One of the interesting things about us is that we’re not really focused on a hypothesis when we come in; we want to start with artifacts. We want to look at the substrate of the organization and explore it. Like archaeologists, you dig a little of the dirt, find the first layer of civilization, and come up with some thinking about what’s going on. You dig the next layer of dirt and find the next piece. It’s important to understand how people actually get things done, and then you can make suggestions about what to do. One of the lessons we learned recently with this engagement was we saw a process and were like, wow, if you did this differently and this differently, you could achieve this huge productivity gain and here’s how you could do it. It was almost like the management consulting version of showing up with a hypothesis, and the ROI would be an enormous number. Our client just looked at us and went, that doesn’t feel right to us. We don’t believe you and don’t understand this. We had to reset and ask, what’s important to you and the way you work? We found this key insight that drove an outcome they didn’t want to change. It was cultural, and it mattered to them. So from that, we said, Oh, okay, now we know this: We have to get really small, micro. We have to look at one small improvement we could make. We did it—it was valuable to them. Now they’re on this path of, hey, this makes sense; what’s the next small thing we could do? This part of our perspective is to take people on a journey one nugget at a time or one, you know… I’ll probably overuse the archaeological metaphor, but we’ll dig down another layer.

Jorge: I think you started touching on something there that I wanted to expand on because we actually have a question from Katherine in the chat. She asks, “Can you talk more about the deliverables to the organizations and businesses supported? I like the term emergent roadmap. What would that include? Detailed documentation? How-to guides?” So, what do we deliver, Greg?

Greg: Yeah, so I think one of the things we’ve done is we prototype from the beginning. We’re constantly making. I can give you an outline of the things we did and want to continue doing. We ran a workshop with our client around how they work, helping them identify jobs to be done or workflows or outcomes that were particularly important to the firm but where they were spending a lot of time. Then we started making stuff with them. We explored the art of the possible together. As we went through this process, two things happened: one, they started learning to use these tools and were surprised by the efficacy of the results. We were surprised sometimes—like, wow, that didn’t work, or that could work if our data structure were more organized. Oh shoot, we need to do that before we can make this happen. In the end, we built, you know, we built an agent. It’s not an autonomous one—it’s one that you work with. There was a huge aha moment in there. I don’t know, maybe Jorge, you were more involved with this and want to talk about the importance of understanding the discernment of an organization and the collective knowledge in being able to build something that sorts through, triages, and does the right work. How did you do that? Talk a little about the last mile of the effort we did.

Jorge: Yeah, and you talked about starting with prototypes and the last mile, which is right: it’s about prototyping throughout the process. You mentioned skepticism, which I expect we’ll encounter a lot, because many suspect there’s a lot of hype around this stuff. The quicker you can get to testing hypotheses and validating hypotheses… When we did the first pass at the workflow archaeology thing in this engagement, we came out with a couple of hypotheses about what might be good uses for AI in this context. The immediate next step should be, “What’s the minimal test we can do to validate this hypothesis?” It might be that the data isn’t there; it might be that the culture isn’t there. It might be, and this is now going to your question, that the knowledge that needs to be articulated as part of this AI assistant or agent or whatever you want to call it is so dispersed culturally in the organization and not described explicitly. A lot of the knowledge—if you want to use tools that help augment people’s work—you have to get people to express what it is that they do.

Greg: And that’s important, right?

Jorge: Exactly. The thing is, people don’t tell you what they do—you have to find other ways of getting that out. Prototyping is one way to do it, right? It’s a way to get that done. That is one of the, I think, deliverables to Katherine’s question. But also to honor the notion of the emergent roadmap, the other thing we worked on in parallel is basically a business case. It’s not just about building a proof of concept here—something that is like a minimal test, a minimal validation of whether there’s any “there” there. If that test proves successful, then what would it mean to scale this? What would it mean to get it into production? You want to come out of this process—not just with a tool that someone can use to automate a particular workflow, but also a sense of direction of where we could go next and how to take this initial experiment and start moving it so it has a larger impact. One way to do that, I think the grown-up way to do that, is to start putting numbers to it and having the numbers be realistic so leadership can make decisions about whether this is something they want to invest in or not.

Greg: Yeah, I think we had another aha moment. We invested in building a pretty comprehensive model; we did time on task, understood the billable rates, the team costs, and how much time it took to accomplish things. We could give a very accurate picture of if the evolution we were promoting—the prototype we had—was utilized at a certain level by the organization; they could achieve this outcome. What was really interesting was and unexpected—they asked a really good question: “Okay, now that we have more time because this effort we solved is going to give us time back, what do we use it for?” That was a really interesting and valuable question and one of the things that’s interesting about small and medium businesses: their perspective was not that they needed fewer people but that they reduced some aspect they didn’t want to manage. They asked how they could use this gift of time toward something meaningful for them and what the value of that would be for the firm. That’s harder for us to solve for, but we can facilitate conversations around goals and outcomes. One of the interesting things about our work is our last client walked away with a recognition of part of their business they didn’t even understand and its implications. They didn’t understand that part of their business they’d been doing forever was consuming more time. It was like a frog boiled in water; if they hadn’t paid attention to it, it would cut their margins to the point where the business would be less successful, and they wouldn’t understand why. This process of workflow archaeology isn’t just about the technology; it’s about helping identify and see yourself as an organization and then ideally craft a path toward a better outcome. To come back to the question that was asked, part of what we did early on—and this is really important—we helped them prioritize the outcomes and workflows against the current state of AI. That gave them confidence: we had this two-by-two framework where the upper right quadrant was high value and easy to do. So we said, “You should just work on those right now.” The other things all sound cool and could be transformational and amazing, but let’s work on practical things of high value that conceptually have high value. Let’s help discover what those are because they may not be the things that people talk about—the things they think are high value are the things they love to do. But in terms of pushing an organization forward or allowing it to achieve its goals, the necessary things often are the important things. If you can make those more straightforward, the benefits accrue over time. Part of what we left them with was a roadmap of what’s the next workflow they should tackle. They don’t need us anymore to do it, which is interesting, too. We taught them how to do it.

Jorge: I wanted to circle back to something you said because it was intentional on our part: helping the client understand their current state better. When we originally discussed the offering, we riffed on an old Velvet Underground song and called it “We’ll Be Your Mirror.” You remember that?

Greg: Right, right.

Jorge: That’s because this technological disruption—this opportunity—presents one of those rare moments where you can step back and examine the state of what you’re doing. Organizations are systems, and long-running organizations are complex systems that have evolved over time to perform their functions. These engagements present the rare opportunity to take a step back and take stock of how the whole system is operating. Obviously, you want to improve how it’s working; that’s the whole point of the engagement. But, at a minimum, if you get nothing else out of it, having that high-level picture—even if we’re just a part of the business—is really valuable. I want to pivot here because we have about six minutes left.

Greg: Yeah.

Jorge: By the way, Katherine is following up and saying they work in government, and this process is very applicable there in addition to small and medium-sized businesses. Yes, I believe that’s right, Katherine. When we say small and medium-sized businesses, departments within large organizations sometimes function like small and medium-sized businesses. Enterprises have different constraints, making them slightly different. I suspect that government does as well. That’s a good point. What I wanted to suggest, Greg, given we only have about five minutes left here—and we didn’t plan this beforehand, so again, very emergent, unfinished conversation. What would be one takeaway for folks tuning in? Something that maybe they can do differently or think differently about this new technology that, I don’t know if I want to complicate by saying, might be counterintuitive or might be surprising. Something we’ve learned that might help them.

Greg: Yeah, I mean, I think culture is really important. People talk about how culture eats strategy for lunch, right? You need to understand what’s important to people. You can anchor this kind of work into that so it feels like it’s part of a journey people are on together. That may sound altruistic and optimistic of me, but personally, I think one of the reasons you and I are doing this is that we want to see real impact and see that impact is meaningful, where humans have agency in the conversation. If you just talk about the technology, you won’t understand that aspects of the way people currently work will stop you from making progress unless you understand it. If you understand it, then you can use that as an anchor to drive something forward. So don’t ignore…

Jorge: Culture. I love that you said culture is important, and I will add that culture is also fragile.

Greg: Very much so.

Jorge: Organizations with a dysfunctional culture probably want to change it, but I would expect those folks might not be looking to institute or add AI to the mix necessarily. So assuming that the culture in your organization is healthy—which was certainly the case with our client—then I think a question becomes how do you introduce such a disruptive technology without ruining it? That’s yet another reason to delve into this new space, but do it mindfully, not with the goal of transforming the whole thing from the ground up day one, but rather, let’s take this one step at a time. Let’s ensure it’s true to who you are as an organization and helps you become more of who you are, as opposed to trying to change you into something completely unrecognizable.

Greg: Also allow you to recognize what change you will have to go through. This isn’t going to happen overnight, right? Even for small and medium-sized organizations, there will be some disruption and impact and roles that will change. But do it in a way that’s intentional and mindful, so you understand the implications. Don’t just do it. I know that’s more than one thing, but I think that’s important. I think you should also make stuff. That’s something to help impress people with—don’t just make anything, but be focused on what you make first. That may not have a benefit immediately, but at least you’re focused on it. Then you learn and make the next thing. Don’t try to do everything at once. Be focused and intentional about the evolution of your organization. If we can help organizations do that, then I think you can give them comfort about their trajectory. Leadership will have agency and ideally communicate that to their employees so they can evolve together in this new environment rather than have it imposed on them.

Jorge: Yeah, that’s a superagency thing, right? It’s not being imposed on me; I’m a participant in this. We are at time. I think this was a great first conversation. We will have more of these. For those who want to follow up with us, our website is unfinishe (without the D)—unfinishe.com—and we do have a Substack where we’ll be posting hopefully fairly regularly what we learn; that’s at thoughts.unfinishe.com—so Unfinishe Thoughts, basically. All right, Greg, thank you. We will let folks know when we have another one of these scheduled.

Greg: Thanks. All right.

Jorge: And thank you to everyone who tuned in, by the way.

We’d love to know your thoughts—especially since we plan to do more of these. Are there questions or topics you’d like to bring to the table? Please let us know in the comments below.

Most robots today aren’t the general-purpose humanoids dreamed up by sci-fi visionaries. Instead, they’re task-specific industrial tools. Why? Simple economics.

Imagine you’re looking to automate a human-staffed automobile factory. There are two ways you could go about it. The first entails designing machines that work within the assembly line’s constraints — i.e., general-purpose automatons that can skillfully navigate real-world contingencies.

These machines would need to respect the factory’s affordances and other agents in the environment. Because of this, they’d have to replicate human capabilities: similar sensing and actuation mechanisms, similar cognitive abilities, similar communication channels, etc. They’d need to switch tasks on-the-fly to perform different jobs as needed.

This is the dream, and there are companies working to make it real. But there’s a problem: humans are very complex. Building one-to-one replacements is challenging with today’s technologies. A factory staffed with humanoids would require huge investments before the first automobile rolled off the line. But more to the point, it’s unnecessary: the goal is cheap cars, not cool robots.

A smarter approach entails redesigning the assembly line to constrain conditions so simpler machines can do specific jobs: transporting components, welding panels, painting doors, etc. By choreographing several simpler robots, you can have an efficient and cost-effective assembly line. This is, in fact, how most cars are built today.

Even if technologies afforded fully agentic humanoid workers, it’s unclear such an assembly line would be more efficient. At the risk of over-generalizing, here’s a simple design principle: Re-architecting workflows for simple agents costs less than engineering complex agents for existing workflows.

Of course, this assumes stable, predictable inputs and outputs. The automobile plant takes in particular materials in specific quantities at predefined cadences and outputs consistent products — a scenario that offers little leeway for variation. Not all industries fit this description. Still, there are cheaper ways to introduce flexibility than using general-purpose automatons.

Now, map this principle onto knowledge work. Many organizations are betting on AI to replace humans. But as with the humanoid factory worker, the technology isn’t quite there yet. Yes, there are some neat demos. Yes, agentic systems can automate complex tasks. But most of these systems operate within tightly constrained conditions and can’t autonomously replace human workers.

And that’s ok. As with the assembly line, fully autonomous, flexible agents are unnecessary in most scenarios. Many workflows can be made more efficient by “rearchitecting the line” around the constraints and capabilities of simpler AIs (such as LLMs) rather than via hypothetical superintelligent agents. Mindfully structured workflows can get you pretty far at a fraction of the cost.

And in any case, why mimic humans — at great expense — when LLMs offer unique capabilities? By analogy, robot arms can be much stronger than human arms, have more degrees of motion, move with greater precision, and repeat motions endlessly without boredom or injury. Conversely, most don’t need the delicate sensory capabilities of human skin or the nuanced motions of fingers.

Which is to say, artificial systems are more capable than humans in some ways and less so in others. Where humans have an indisputable edge is in their flexibility. A person can take on many different tasks and serve different roles — including some they weren’t asked to do. It’ll be a long time before AIs can catch up with human flexibility and initiative. In the meantime, organizations aspiring to implement general-purpose systems will pay an onerous — and often unnecessary — “flexibility tax.”

When considering AI optimizations, start by understanding your organization’s knowledge pipelines — i.e., how information flows through the org. When you do, you’ll recognize opportunities to automate processes in cost-effective ways. You’ll also recognize opportunities to get rid of processes. No reason to automate things that shouldn’t be happening at all!

As with industrial flows, using AI to automate knowledge work is more cost-effective if you “rearchitect the line” — i.e., constrain variances, standardize interfaces, provide predictable inputs, etc. Yes, AGI might make it all obsolete. But AGI doesn’t exist yet, and LLMs are already powerful enough to serve as “robot arms” that boost your knowledge pipelines.

image generated by Google Gemini


We walked into the architecture firm and began analyzing their construction administration processes. After mapping their workflows and analyzing their project data, we discovered something striking: they were spending substantial resources annually on administrative tasks that AI could potentially automate. The numbers were undeniable. The vision was compelling. We proposed a wholesale set of changes that we felt AI enabled tools could deliver.

They politely thanked us and asked if we could start with something smaller.

This moment taught us everything about why most AI implementations fail before they begin. The problem isn’t technical capability or even budget—it’s that we’re trying to sell the future to people who are drowning in today’s broken processes.

The Big Picture Trap

When you can see the forest, it’s tempting to point out how much timber could be harvested. But the people living among the trees are focused on not getting lost.

We came prepared to demonstrate how AI could eliminate substantial administrative burden in construction administration. What we discovered instead was that before anyone could believe in transformation, we needed to prove we understood their reality.

That reality looked like this:

• Architects spending a quarter of their time on administrative tasks they never learned in design school — and which few people like doing now

• Critical project information scattered across email threads, specification documents, and tacit knowledge

• Workarounds built on top of workarounds, creating fragile systems that somehow kept projects moving

• Legacy system inertia (their current project management platform) that had shaped inefficient processes everyone had learned to work around

The big efficiency vision felt abstract. The 10 minutes they spent every morning hunting through emails for RFIs (Requests for Information—formal questions contractors send to architects asking for clarification on design details) that needed their attention? That felt urgent.

Workflow Archaeology: Digging to the Bones

Forget the process diagrams. Real workflow discovery happens through rigorous field research, not idealized explanations of how work should flow.

We conducted interviews with architects across different experience levels, ran working groups to map actual workflows, and dissected real RFI emails from their recent projects. We surveyed the entire firm about time allocation—over 60% responded, revealing that architects consistently underestimated how much time they spent on administrative tasks.

Most importantly, we analyzed their actual project data: tens of thousands of RFIs and submittals across dozens of projects, with massive variation in distribution. Some projects generated thousands of items; others fewer than a hundred. The patterns revealed bottlenecks invisible in abstract process discussions.

One insight emerged clearly from all this research: email is the interface between contractors and architects. While the firm had invested in web-based project management tools, the real work happened in Outlook. Contractors sent RFIs via email. Architects responded via email. The web tools served as repositories, but email remained the conversation medium where professionals felt comfortable working.

Service Design for AI Implementation

Observe Before You Optimize

AI consulting often begins with identifying processes that could be automated. We started by understanding which processes were already broken.

The difference is crucial. Automating a bad process makes it efficiently bad. Understanding why the process breaks down reveals where intelligence—artificial or otherwise—can provide the most leverage.

In architecture firms, we found that the stated workflow (”we review RFIs systematically”) rarely matched the actual workflow (”Sarah always knows where to find the answer, so we ask Sarah”). The AI opportunity wasn’t replacing systematic review—it was scaling Sarah’s institutional knowledge.

Follow the Energy

Through our surveys and prototype testing, we tracked not just what people did, but where they lost energy. The moment an architect’s shoulders sagged wasn’t when they were analyzing complex technical problems—it was when they realized they’d have to dig through 1,800 pages of specifications to find one relevant clause.

Architects Love Solving Design Problems

They hate hunting through documents to find information they know exists somewhere. This energy differential pointed us toward our automation target: not the complex analysis, but the tedious information retrieval and administrative overhead that precedes analysis.

Start With the Smallest Viable Improvement—In the Right Place

Based on our research, we’re building two interconnected tools that work where architects actually spend their time: in email.

First, an AI agent that reads incoming RFI emails and automatically creates properly formatted project management tickets with the right metadata. Second, an AI assistant that provides instant analysis of RFI content, suggests relevant specification sections, and offers response recommendations—all in the place where their email lives.

Together, these would eliminate the administrative overhead per item and provide substantial research assistance. More importantly, they work within their existing email-centric workflow.

The Evolution Model We’re Testing

Phase 0: Grow Competence and Confidence with AI

Co-explore the problem space with the client to help them understand the emerging capabilities of AI tools. A basic tenet for our work is we are doing it together with the client so that they learn along with us.

Phase 1: Automate the Annoying

We’re building the email-to-ticket automation first. If it works as expected, it’ll solve a daily frustration without requiring anyone to change how they think about their work—and prove we understand their workflow well enough to improve it.

Phase 2: Augment the Analysis

With trust established, we could then introduce AI that helps with specification comparison—still supporting human judgment, not replacing it. The AI would become a research assistant that instantly knows where to look in 1,800-page documents.

Phase 3: Orchestrate the Workflow

Only after proving value in phases 1 and 2 would we propose end-to-end process transformation. By then, the team would have experienced AI as a helpful colleague rather than a threatening replacement.

Our hypothesis: skipping directly to Phase 3—even with superior technology—usually fails because it asks people to trust a future they can’t yet imagine - crawl before you run!

Key Ingredient to Success: Use AI to help structure unstructured data. Organizations are full of unstructured data that could be useful if only it was organized better.

What We’re Learning About Change Management

Process Attachment

People defend inefficient workflows they’ve mastered. This isn’t irrationality—it’s professional competence. They know exactly where to find information in their current system, even if that system looks chaotic to outsiders.

We’re learning that successful AI implementation requires respecting this expertise while gradually demonstrating that intelligence can be enhanced, not just replaced.

Trust Building Through Small Successes

Our hypothesis is that every small automation success will create permission for slightly larger changes. The compound effect of trust may prove more valuable than the compound effect of efficiency gains.

The Design Methods That Revealed Hidden Insights

Systematic Research Over Assumptions

Instead of relying on stakeholder interviews alone, we built a comprehensive research program. We surveyed the entire firm about time allocation and got over 60% response rates. We analyzed their complete project dataset, revealing massive variation that abstract discussions had missed.

Email Dissection as Ethnographic Method

We collected and analyzed actual RFI emails from recent projects, identifying patterns in language, formatting, and information density. This revealed that contractors already provide most of the metadata needed for project management—it’s just buried in prose rather than structured fields.

Prototype Everything, Test with Real Data

We built multiple prototypes using actual project specifications and RFI content, not sanitized demo scenarios. Each prototype taught us something about the gap between what we thought would work and what actually helped professionals make decisions faster. And with AI we can now build functional prototypes incredibly fast by ourselves rather than relying on developers.

Benchmarking Reality Against Ideals

We researched industry standards and available tools, comparing the firm’s performance against both competitors and best-in-class examples. This grounded our efficiency targets in achievable improvements rather than theoretical maximums.

Lessons for Other Professional Services

Start with Observation, Not Solution

The AI tool you think they need rarely matches what actually helps them. Domain expertise beats technical sophistication when it comes to identifying the right problems to solve.

Find the Keystone Habit

Look for the one small change that unlocks bigger improvements. Email processing became our gateway—unglamorous but immediately valuable and working within existing workflows rather than forcing new ones.

Respect the Craft

Professional services firms aren’t just processing information—they’re applying judgment developed through years of experience. AI implementations that acknowledge and augment this expertise succeed; those that ignore it fail.

Meet People Where They Work

Don’t force adoption of new interfaces when existing tools (like email) already serve as the natural workflow hub. The most powerful AI might be invisible to users, working behind the scenes in familiar environments.

Don’t Boil the Ocean

Resist the temptation to use AI to solve all the problems in one go. Instead, pick small yet annoying and expensive, clearly-defined problems to automate.

The Compound Effect We’re Betting On

We’re betting that the boring AI applications—the ones that eliminate minutes of document hunting rather than promising to revolutionize entire industries—will deliver the biggest improvements to professional satisfaction.

The patient capital approach to AI implementation requires resisting the urge to lead with transformation and instead beginning with observation, empathy, and very small wins.

Sometimes the most innovative thing you can do is solve the mundane problems that everyone has learned to tolerate.

Always Unfinished

This is why we call ourselves Unfinishe_. The work is never done—not because we’re incomplete, but because organizations are living systems that constantly evolve. Workflows shift. Tools change. People develop new expertise and face new challenges. The “finished” AI solution becomes obsolete the moment the organization adapts around it.

Our approach embraces this perpetual evolution. We’re not building toward a perfect end state; we’re creating adaptive systems that improve alongside the people who use them. Phase 1 will reveal insights that reshape Phase 2. Phase 2 will surface needs we can’t anticipate today. Each implementation teaches us something that informs the next.

Workflow archaeology isn’t a one-time discovery process—it’s an ongoing practice of observation, experimentation, and refinement. The small bite we’re taking today creates space for the next small bite, which creates space for the next. Progress compounds not through grand transformation but through continuous, incremental evolution.

We’ll know soon whether this specific approach works with this architecture firm. But we’ve already learned that workflow archaeology—understanding the actual work before trying to improve it—reveals opportunities that process diagrams and stakeholder interviews miss entirely.

The work remains unfinished. And that’s exactly the point.

What workflow archaeology have you discovered in your organization? Where do people lose energy that they don’t even recognize as lost?

We’re building a playbook for human-centered AI implementation, one small bite at a time.

Learn more about our approach at unfinishe.com

AI is inherently conservative. I don’t mean this in the political sense: here, ‘conservative’ has a lowercase c. Rather, I mean that, because of how they’re architected, large language models favor and perpetuate long-established frameworks and ideas over upstarts. This has implications for how you use AIs to develop your information infrastructure.

I won’t go into how LLMs work here. The main point is that models are trained from existing data. On day one, they only “know” about what’s in the training corpus. The more information there is about a particular topic, the better the model will do with queries about that topic.

Naturally, the corpus includes more information about older mainstream subjects than newer niche subjects. As a result, models do better on older stuff. For example, it’s more likely an LLM has been trained on the full text of Bleak House than on a more recent novel. An LLM-generated summary of the former will likely be more accurate than the latter.

Yes, newer chatbots include research modes that let them search the web. But even so, LLMs tend do better when the core model “knows” more about the subject. Of course, this applies to more than just prose: LLMs also produce better answers to questions about older, more established ideas in other domains as well.

Subscribe now

A few real-world examples

A few months ago, I asked the then-new ChatGPT o3 “reasoning” model for help troubleshooting my old-school Panasonic Micro Four-Thirds camera. The device was unresponsive after I’d plugged it into an unfamiliar charger. I wanted to know if there was anything I could do to unbrick it.

At the time, folks were saying o3 had near-AGI capabilities. In my case, it produced a textbook hallucination: long, authoritative, and repeatedly mistaken explanations of how to disassemble the camera and which parts to order. Fortunately, I had enough sense to doubt its recommendations.

The problem? The parts and procedure it suggested were indeed for a Panasonic Micro Four-Thirds camera, just not my model. My sense is that when dealing with a niche product within a niche category, the LLM didn’t have enough to go on. It tried the best it could, but the result was worse than saying “I don’t know.”

I’ve also experienced this issue when using LLMs for software development. Recently, I asked both Claude and ChatGPT for help in implementing a workflow in Langflow, a relatively new system for developing agentic applications. Both chatbots suggested I try nonexistent features or produced broken code. (Yes, even though I put GPT 5 into “thinking” mode.)

In this case, both Claude and ChatGPT were likely hampered by the fact that 1) Langflow is relatively new and 2) it has a visual (rather than text-based) interface. Interactions with the chatbots consisted of me pasting screenshots of the dev environment and the LLMs offering instructions of which UI elements to ‘wire up.’ Less than ideal.

Conversely, for me, both LLMs have succeeded brilliantly at writing Emacs Lisp config files, Unix shell scripts, and Python applications. Not only are these text-based platforms, but they’ve been used widely for a long time. There are decades’ worth of material online on how to solve problems with Python, Elisp, and Bash.

But this isn’t just about longevity. I’ve had poor experiences using LLMs with another long-lived programming language: AppleScript. My guess is there aren’t enough examples in the training corpus of how to solve problems with AppleScript. Basically, LLMs do better with systems supported by lots of Stack Overflow posts.

Entrenching established technologies

And here’s where we come to the word ‘perpetuate’ in the opening. Although I don’t have traffic stats, my sense is LLMs are replacing the Stack Overflows of the world. As more developers turn to LLMs for answers, they eschew the types of interactions — blog posts, forum questions, etc. — that would produce the next generation’s training corpus.

This will place new systems at a disadvantage. We’ll get worse suggestions for a new development framework or language if the LLMs don’t know enough about it. And LLMs won’t know about it if people don’t post about it — which they won’t do if LLMs are answering all their one-off dev questions.

A corollary: applications written with older languages and frameworks will be easier to develop and maintain than those created using newer systems. As a result, established programming languages such as Python, Perl, Lisp, etc. will become more entrenched. A vicious (?) cycle ensues.

I added the question mark because I’m not convinced this is a bad thing. Standing on the shoulders of giants is a time-honored way to build higher and faster. (Especially if the giants are unlikely to jerk you around. Open source technologies like Python, Elisp, and Perl are trustworthy and predictable.)

Implications for tech choices

The idea that AI entrenches incumbents has counter-intuitive implications. First, even though LLMs themselves are an exciting new technology, you should favor older, established, mainstream technologies over newer, unproven alternatives — especially when you use LLMs to develop software.

Even amazing new features (e.g., Langflow’s visual dev environment) must be weighed against older systems’ overwhelming advantages in an AI-augmented world. Put simply, new applications built atop established technologies will be easier to develop and maintain — and not just by humans, but also by AIs and AI/human centaurs.

Second, Lindy is in effect here. You don’t want to build atop technologies that might soon become obsolete. Ironically, in an AI-augmented world, older technologies stand a better chance of sticking around. New entrants have a formidable disadvantage because LLMs don’t know as much about them — and perhaps never will.

Third, there’s a reason why ‘language’ is one of the Ls in LLM: these systems are trained on text and fare best when dealing with text queries about natively text-based systems such as novels and Python code. You’ll get better results when solving problems in systems that use plain text (e.g., a directory full of .py files) rather than fancy UIs.

Toward a conservative approach to AI

LLMs are one of the most disruptive technologies in our lifetime. But structurally, they’re inherently conservative. Their training leads them to favor established frameworks and ideas. Often, this leaves new or niche technologies and ideas at a disadvantage.

This has implications for your tech choices, especially when you’re using AI to develop information systems. Favoring older, more established programming languages and frameworks will lead to more efficient development, easier maintenance, and better outcomes.

As is often the case with innovation, the challenge is balancing novel approaches with the reliability of proven solutions. The goal is harnessing the power, speed, and scale of LLMs while building on solid foundations. Ultimately, building wisely with AI calls for adopting the new while recognizing the value of the old.

This post first appeared on jarango.com.