“Six weeks ago, I was like, this is a disaster,” Chris McClanahan told me in our recent conversation about how the Tanzu product teams have been using AI. It got better though. Now the team is able to get feedback on feature ideas in a day or two and speed up the development process. As Chris put it: “ideation, which used to take, you know, six, seven, eight weeks to go through a single run of engineering is now a couple days at most.”

The team got the hang of it by changing how they worked, re-organizing team structures, and also spending a lot of time teaching the AI about our product and how to work with the humans.

Now product managers are speeding up the time it takes from talking with customers about feature requests, documenting them, and refining what those features look like with UX, developers, and most critically customers. When you can talk with a customer on Monday and show them a prototype for how the feature would look on Tuesday, you speed up the development of the product. More importantly, because you have a stream of high quality customer feedback through the process, the results match what the customers want and need. 

Chris is one of the co-leads of product management for Tanzu Platform, a large, complex, enterprise system that’s been around for well over a decade and used by many of the largest organizations around. This is similar to the software estates many of our customers have, and we face many of the same challenges when applying AI to the entire software development process.

So, let’s get into what the Tanzu product team has learned that works and does not work with AI and software development.

Pods

When you introduce a new technology, it’s often the “culture” that hold you back. Usually, this is because organizations fail to change how they work and are structured to take advantage of the new technology. “Technology is easy, culture is hard,” the saying goes.

“ You have to do some organizational changes,” the general manager of Tanzu, Purnima Padmanabhan said in another conversation. “ So, we reconfigured some of our development teams into a pod-like model, where we had the software developers paired with the product managers, the UX, the architects, the end-to-end testers all together in a small pod, and gave them more responsibility with AI, but also gave them more accountability so that they could discuss things faster, resolve things faster, and move much faster.”

A team in one pod, instead of spread across different teams, means you don’t need to cross organizational boundaries to pass work along. When the rate of feedback and developing new features is compressed, you don’t have time to pass the work product from one team to another. In a normal structure, the product managers would then schedule time to talk with the developers and pass off the feature specification, explaining it, going back and forth with the developers, and so forth. 

An organization working like that becomes its own bottleneck when an AI agent can go from idea to working prototype in a couple of hours. This is why you need to have everyone on the same team, in the same pod. There’s no time to schedule a meeting, so to speak.

Onboarding and Continuous Context

One of the reasons AI is good at coding is that it’s been trained on millions of lines of code from open source projects, developer support forums, and similar sources. This is all public information. But, the ongoing knowledge of how customers use your product, not to mention how they have been using it, is not publicly available. To get over that, you need to do a tremendous amount of onboarding for an AI.

“It’s like a new hire,” Chris said, “what am I going to give a new hire to get them going with the platform?” (26:20)

You feed the AI a corpus of public and private context.  Chris goes on: “ we fed it knowledge base articles, and then we fed it documentation, and then we fed it customer information. And then we fed it, you know, historical blogs.” (26:58)

That’s the process the PM team used to give the AI the initial context.

And then, ongoing, as you discover more pieces of hidden knowledge, you need to store those off for the AI. As with Agent Skills, if you find yourself telling the AI something more than once, it’s good to document it. This, of course, means building up markdown files of what you want the AI to do and avoid. You’re building up a context of gotchas and desired behavior. To me, this is a continuous context process. You’re documenting the existing and new institutional knowledge, this time in a way AI can use.

Integrated by the AI

Once you have this continuous context in place you can reverse the roles and have the AI ask you questions. Chris says they tell the AI to ask “the questions that you need to help you plan better before we go and execute on anything.” 

“This could be a five or 10-minute dialogue that I do back and forth of asking questions,” he says, “and I keep saying, ‘Ask me the questions you need.’ And eventually we get to a point where we’re like, ‘Ah, this is good. Let’s, let’s go with it.'” (41:33)

You see this, of course, in programming with an AI. You move to planning mode and part of that is having the AI interview you and ask clarifying questions. The same applies to product management. As Chris puts it, it helps the AI learn the intentions you have with features.

AI prototyping

As mentioned numerous times, AI speeds up nearly everything. And in product management, this means it speeds up validating requirements and how the final implementation might look to a customer. When you have a new idea for a feature, usually from a customer, in a day or less you can get back to them with a proposal for what it will look like. This isn’t  just an explanation,  mock-up, or diagrams, but an working prototype that they can use and experiment with. 

“It’s going through and it’s spitting out a prototype even within a couple hours that we can get back on the call with the customer and go, ‘Hey, is this what you were looking at?’ And they’re like, ‘That’s exactly what I want.’ ‘Oh, great. We’re putting it into a path,’ or, ‘We’re gonna give you a sub release,” or something like that in the future.”  (35:59) 

But, you have to be comfortable with this new way of working. And, you also need to adjust the process. It’s not as important to get it perfect the first time. Indeed, you could spend all the time in the world getting it perfect the first time, show it to the customer, and then have them say “no, that’s not exactly what we want.” Iterating faster in the product phase of software, thus, speeds things up, but also lets you implement better features, closer to what people want.

AI Fatigue

If you’ve worked with AI for awhile, you’ll likely notice an exhausting feeling at the end of the day. Because AI can churn through work so quickly, you easily enter a flow state where you’re in a dopamine-rewarding loop of ask-do-feedback. This tight loop focuses most people and they often look-up hours later unaware that time has passed. Programmers experience this all the time, and now other roles are experiencing it too. 

There’s also some entrancing about watching AI work, explaining itself along the way. As Chris put it, “ I will have staring ‘AI syndrome’ where I’ve done something, and now I’m just reading how it’s thinking, and I’m just sitting there until, like, my eyes are blurry, and I’m like, ‘I gotta stop looking at this thing.'” (45:32)

When it comes to enterprise software, this is obviously a bad state to work in. When you have a human in the loop, verifying and checking what AI does, that human needs to be alert, sharp, and skeptical. You’re looking for problems in a sea of AI happy-talk. “What we found is you can get into fatigue on the skeptic role,” Purnima said, “So, we have to keep changing that skeptic role, so that the brain stays fresh and you’re looking at what is being produced with the context.” 

This is another reason why the pod structure is important: you want the ability to rotate people in and of the ongoing projects and sub-projects.

What else gets automated

There’s a few other things Chris mentioned that I want to highlight.

“Paperwork” – in enterprise product management there is a lot, well, “paperwork.” There are requirement requests to put together, specifications, reporting on sessions with customers and others who are driving requirements…you know, a lot of “go update Jira.” Putting together the basics of this admin work is the kind of thing that AI excels at, and now the team has much more time and energy to focus on the actual innovation and thinking behind features.

Parallel PRDs – as with programming, product managers can work on multiple streams of work at once. “ I’ve got five features going in at one time,” Chris says (49:56). This maps to the mindset you hear a lot with AI: individuals shift up to being managers.

An outside perspective – as Chris puts in, “you have some great ideas as a product manager – because let me tell you, we have some great ideas, and about ten percent of them are good ideas.” Once the PM team aligned the AI with ten years of institutional knowledge, including customer requests and usage, it became a capable outside perspective to test out assumptions about all those great ideas. “The agent will actually tell you like, “Nobody’s gonna use this.”

Getting Started

So, how do you get all of this started? The Tanzu experience shows that you start with the organization, put together a pod of the different roles needed to go end-to-end. Don’t try make the old process better with AI, take advantage of AI to put in place a new process. 

Next, Chris emphasized that the first move isn’t a massive mandate, but starting with a few “spot pods” to prove it out and learn how to fit AI to your organization. This is a period of trial and error, and it can feel like you’re not getting anywhere. But this is part of the rythem of how it works: small iterations, small loops to plan, try, and look at feedback. You adjust as you go.

The real shift starts when you stop planning for months and just start building. Instead of spending weeks aligning on a perfect spec, you push three versions through the pipeline in days and let the working prototypes teach you what the feature should be. 

As Chris puts it, the product manager role transforms into an “Intent Director,” where the primary is carrying customer intent into the pipeline and then interrogating the AI to ensure it understands the business context. Eventually you’ll start to see some 24-hour turnaround on a feature that used to take six months. Then, you have a new, delightful problem to solve: coming up with a plan for what to do with the time you’ve reclaimed.