VP of Product Design says product, design, and engineering must have shared AI scaffolding to collaborate effectively

Andy Vitale is VP of both Product Design and the AI Center of Excellence at Taxwell.

We sat down with Andy to discuss how design, product, and engineering can effectively collaborate with AI. Here's what he told us.

Where design, tech, and organization meet

I'm Andy Vitale, a design executive who has spent the last decade building and shipping AI-enabled products. Today, I lead Design and the AI Center of Excellence at Taxwell, where we build software products that support tens of millions of tax returns each year for more than 90,000 tax professionals and 3 million DIY filers.

The work ranges from consumer products that need to feel simple under real financial pressure, to professional tools where depth and reliability matter more than hand-holding. My org covers consumer tax, professional tax, the shared platform underneath both, and newer product areas we're still shaping. The team organizes around those domains, and we're shifting toward an AI-assisted delivery model, so design works closer to the product instead of handing off to it.

My AI journey started in 2015 with natural language processing in healthcare at 3M. This was my first real exposure to designing products around machine intelligence, not just interfaces. Then, I led design at Rocket, seeing how technology moves through a large organization. Later, as Chief Design Officer at Constant Contact, I saw generative AI start reshaping what products could do. Now, at Taxwell, I make our products smarter and our teams more capable of building with AI fluently.

I've always been drawn to the seams — where design, technology, and the organization meet. AI has made those seams the most important part of the job. This moment feels like what my whole path prepared me for.

How to build a shared AI foundation across disciplines

We stopped treating AI as a feature to add and started treating it as infrastructure to build. Over the last year, design, product, and engineering have partnered to build a foundation that lets the team move faster without moving more carelessly.

That means shared scaffolding and harnesses for working with models, and AI-enabled steps from concept to validation. We don't need to wait to establish a way to test an idea against AI.

The second part of that change is that the team now builds using the same materials and tools instead of designing in one place and handing off for rebuilding elsewhere. That collapses the seams where work usually gets lost or distorted. When a designer works in the same environment where the product is made, the conversation stops being about specs and handoffs and becomes about the product itself.

The result is speed and accuracy at the same time, which usually trade off against each other. The shared foundation means we move faster because the hard parts are already built and reusable. Working with the same tools means fewer translation errors, because there are fewer translations. The team spends its time on judgment, rather than on rebuilding each other's work.

The result was a series of zero-to-one launches. A small team can now carry an idea the whole way, moving from concept to working software in weeks instead of cycles of planning and handoffs.

An AI-enabled workflow from concept to software

I'll walk through our process for taking an idea from concept to working software, because AI transformed this workflow the most for us.

It starts with discovery, and AI is involved from the first minute. Before anyone designs anything, we use AI to gather existing knowledge about the problem, patterns from research and support data, prior attempts, and relevant tax scenarios. Instead of a blank page, the team starts with a synthesized point of view to react to and pressure-test.

As we shape the idea, we use synthetic users for ideation. Built from our behavioral research, these users let us explore how different kinds of filers might respond to an approach before we commit to it. They are an ideation tool that widens the directions we consider and helps us find weak spots in our thinking early, not a stand-in for real users later.

Next, we move into building, which is where the old handoff used to occur. As I mentioned, we work through the concept directly in shared materials and tools, the same environment where we build the product, rather than designing in one place and writing a spec for someone else to rebuild it. A designer can quickly create a real, working prototype, not just a picture of one. This matters because we now reason about the product's actual behavior, not a representation of it.

Then, we validate with real feedback. We use AI to moderate testing rounds, allowing us to run far more sessions, more consistently, than a human-moderated schedule would. Cheap, fast feedback comes early, and it feeds directly into the same working artifact, not a new round of specs. Because design, prototype, and build all use shared tooling, the loop from "we learned something" to "the product now reflects it" is short. The conversation focuses on the product itself instead of translating between documents.

Throughout the process, a person remains accountable for the output. AI widens inputs and speeds up the path, but we retain judgment about what is correct, compliant, and truly good for someone filing under real stress. In a regulated domain, that is exactly where it should be.

As a result, a small team can take an idea from a rough concept to working software in weeks, eliminating the translation losses and waiting that previously occurred between stages.

Why AI is responsible for the path to a decision, but not the decision itself

We rely on AI most heavily in the exploratory work phases, where the cost of being wrong is low, and the value of moving fast is high.

In discovery, AI helps us quickly become informed. It compiles existing knowledge, identifies patterns across research and support data, and provides a head start on understanding a problem, rather than starting from scratch.

In experimentation and prototyping, AI enables us to move from idea to something testable in a fraction of the time. We can create a working prototype and use AI to moderate some user testing, which allows us to run more sessions, more consistently, than a human-moderated schedule would ever allow.

For UX decisions, AI offers a quick second opinion. It helps us stress-test flows, review behavioral data, and identify where users may hesitate or drop off. It broadens the inputs a designer works with.

But the decision itself remains human, and deliberately so. AI excels at telling us what is happening and what tends to work. It does not decide the experience we deliver to the person on the other side of the screen. Prioritization and judgments about whether an experience is good, honest, and respectful of someone filing their taxes under real stress remain with us.

I think of it this way: AI expands inputs and accelerates the path to a decision. It does not make decisions that require taste, accountability, or care for the person we design for.

Andy Shares

We rely on AI most heavily in the exploratory work phases, where the cost of being wrong is low, and the value of moving fast is high. I think of it this way: AI expands inputs and accelerates the path to a decision. It does not make decisions that require taste, accountability, or care for the person we design for.

How AI's benefits also expose weaknesses

The clearest good result is speed. We shipped a string of zero-to-one products and features in a single tax season that previously would have taken far longer to get off the ground, including a custom Claude connector we stood up in days, rather than months. AI-moderated testing enabled us to run far more rounds, and to run them more consistently, than we could with human moderators alone. As a result, we were able to make decisions based on more evidence earlier.

But moving fast exposed every weakness in our process. Without the right guardrails, speed led to rework, and the pace asked a lot of the team. AI accelerated our strengths and made our gaps more obvious.

The real result, which I want other leaders to hear, is that teams that performed well had healthy fundamentals to begin with. AI is an accelerant. It rewards good process and exposes gaps; therefore, building those fundamentals matters more now, not less.

Why AI struggles in complex product scenarios

AI has most clearly underdelivered in the messy middle of the work, the part between a promising prototype and something you can ship with confidence.

It genuinely excels at getting you to a first version fast. It does not close the last mile. The further you get from a clean, well-defined problem, the more work falls back to people. Edge cases, complex tax scenarios deviating from the common path, and judgment calls about what's correct and compliant still require the same human effort they always did.

That's the real limit. You're only as fast as the slowest part of your process. Early speed is real, but it doesn't compound as expected because the rest of the system does not change at the same pace.

Why AI works best as a thinking partner

In my experience, AI delivers the most when treated as a thinking partner, not an answer machine.

In a domain like ours, accuracy and accountability are not optional, so the value isn't in generating an answer and moving on. It lies in using AI to reach a more thoroughly considered answer faster.

When our teams use it to explore options, pressure-test their thinking, and move more quickly through parts they already grasp, it acts as a real multiplier.

Andy Shares

In a domain like ours, accuracy and accountability are not optional, so the value isn’t in generating an answer and moving on. It lies in using AI to reach a more thoroughly considered answer faster.

Why product leaders must manage how users receive an AI product

The hardest part of launching AI isn't the technology; it's how people receive it.

My first AI product, in 2015, involved auto-suggested medical coding in healthcare. The system read clinical documentation and suggested the right codes, a task that professional medical coders had always done by hand. I focused on whether the suggestions would be accurate. I underestimated the question the coders themselves quietly asked: Is this here to replace me?

That fear shapes everything, whether you address it or not. It shows up as resistance, as quiet non-adoption, as people technically going along with it while hoping it fails. And it was completely reasonable.

We put a tool in front of people that did a version of their job without first naming what it meant for them, so they filled that silence with the worst-case version. I learned you can't out-feature that fear. No amount of accuracy answers the question they're asking.

I've carried that lesson into every AI product since. You introduce the change and the meaning of the change at the same time. The technology question is the easy one. The human one is where these things succeed or fail.

Why design systems need to be overhauled

If your design system only lives in a design file, every AI generation in the company comes out slightly off-brand, and someone must reconcile it later. This reconciliation work is the new tax that teams quietly pay for not getting ahead of this.

So, redesign the design system to stop treating it as a reference document and start treating it as a runtime artifact — something that lives inside the actual tools generating the work.

This means more than a component library. It means packaging design tokens and components so tools and teams can pull them directly into code, distribute them as consumable packages, and pair them with accompanying skills and best practices — the rules and context an AI tool needs to use the system correctly. When standards, components, and know-how all live where the work happens, the brand shows up from the first prompt instead of getting bolted on at the end.

When you get it right, your design standards are embedded in everything the company ships, no matter who produced it or which tool they used. The system stops being something people reference after the fact and quietly governs quality at scale.

Why CPOs must do the work themselves

My advice is simple. Jump in. Do the work yourself, now, with your own hands.

Many leaders instinctively hand AI to their teams, wait for best practices to emerge, and then set direction based on what they learn. That worked for past shifts. It does not work for this one. It moves too fast, and the gap between those using the tools and those discussing them widens every week. If you are prescribing tools you have never opened, everyone in the room can tell.

I spend much of my week hands-on in these tools, partly because I genuinely enjoy the work, but mostly because I believe you cannot credibly lead a team through a change you only observe. By building with it, you learn what's real and what's hype. You earn the right to set direction and make far better calls about where AI fits and where it does not.

So, stop treating this as something to delegate and study from a distance. Spend real time in the work. Ship something small. Feel where it helps and where it breaks. The leaders who emerge ahead will be those who engage with this moment, not those who wait for it to settle.

Follow along

You can follow Andy Vitale's work at andyvitale.com and on LinkedIn.

More expert interviews to come on The CPO Club!