AI is still single-player. A Denver panel on what that’s doing to designers, engineers, and PMs.
On September 14 I joined a panel in Denver called “Blurred Lines,” hosted by AI & Product Colorado. The premise came from our moderator, Lauri Hofherr. Over the past year she kept meeting engineers writing PRDs, product managers coding prototypes, and designers doing all of the above. She’d billed the event as “Everyone’s a little bit PM now.”
To kick things off, she read one of my LinkedIn posts back to the room:
Design: Why do PMs think what AI built is usable?
Engineering: Why do designers think what AI built is shippable?
PMs: Why does engineering not want to move faster and code with AI?AI is still single-player. Every time one of us reaches for it, we solve our own piece alone — faster, but alone. The trio that used to build the thing together has stopped building it together.
The original post is still open for comments if you want to add your own take.
Lauri’s question to the panel was whether that’s true. Here’s who answered:
- Jake Taylor, Senior Director of Product Design and Research at JumpCloud, who spent the past year leading JumpCloud’s move to an AI-native product development process
- Riley Scardina, principal technical recruiter at Code Talent, which hires for early-stage and high-growth companies
- Jason Fletchall, fractional product and tech for startups with non-technical founding teams, after 15 years in product at companies like eBay and HelloFresh
- Me (Jenny Wanger). I coach product leaders through team transformations, including AI adoption.
The conversation below is edited for length and clarity and grouped by topic, so it doesn’t always follow the order of the evening. Questions from the audience are marked.
Has building together turned into building alone, faster?
Jake: I don’t see the speed and efficiency yet. It depends on the organization you’re in and the competencies within the disciplines.
PM has a great perspective on the business and the user. Design still has a focus on experience and the user. I still really want to respect the boundaries of what people are good at.
Snap was one of the more famous companies that only hired product-focused designers, well into hundreds of millions in revenue. You can’t find those people all the time. You can find very good individual disciplines.
I’m more than happy to encourage and grow the individuals who want to cross the lines and do things. And they have to be pretty good to do those things, just to be clear.
So until we get to that point, I think it’s still three in a box, the trio. That’s what it takes, in my mind, to build a successful product.
Jason, you’re basically running the single-player model with your clients. At what point does that stop working?
Jason: With AI tools I can get a lot further with a startup than I used to. It used to be that I could do the research, work out business viability, and understand the customer problems. But if we wanted to prototype something and get it in front of an actual customer, we needed a developer.
Now we don’t necessarily need the developer at that stage. We will need the developer and dedicated design once we’ve gone beyond initial learning with customers, we have a real product with real customers, and we want to grow it and scale it.
Once you’re getting to more users, the decisions you’re making carry much higher risk, and you want to start focusing more with the different disciplines.
Jenny: That’s the exact logic I keep hearing. “We can do the prototype, so we don’t need to involve the developer in customer discovery right now. We’ll pull them in later when we need them.”
I’m seeing that at a client right now. The PM is saying, “I’m not going to bother design with this, because they’re busy. I can knock it out with Claude, get it pretty far, and loop design in later.”
All three roles, talking about the other two, are saying “I’ll call the other person later. I can get this further right now.” But there’s a huge cost to that.
Jake: There’s a debt that you rack up.
Jenny: You are racking up debt. And it feels so easy to do it single player.
I can be on my phone on a walk, throw something out there, and have a prototype when I get home. So I don’t need to be in a meeting, because I can be on a walk. That’s where we’re running into the friction.
Jake, you spent the past year redrawing where design, product, and engineering start and stop at JumpCloud. Did that fix the collaboration problem, or just move it?
Jake: It’s just a different mess.
The process is defined, it’s documented, it’s enabled. What I’m seeing now is that PMs, as they should, are very into the feature they’re building. But they’re investing way too much time in that idea.
By the time it gets to my team, the person who spent 30 hours and loves their prototype made a ton of user experience mistakes along the way. It didn’t get them nearly as far as they thought.
My team now has to backtrack, figure out what they were actually trying to achieve, and align it to the good patterns we have in the product.
They weren’t using the components from the design system we gave them. They went astray with a lot of different flows. So there’s additional tech debt that immediately got tacked on.
The process is supposed to be: get your idea onto the screen, then start being collaborative, and my team will help you build it the right way. Just like engineering helps us when my team messes something up.
Riley, how is this showing up in hiring?
Riley: People are really burnt out, because they’re having to do things they don’t want to do, or that they’re not necessarily the best at.
We work on a lot of product engineering roles, and startups in the Bay Area in particular want the product engineer to get in front of customers, do the designs, and build out everything on the back end.
They’re all looking for that generalist, that builder, so everyone’s competing for the same profile. And not a lot of people want to do it, because they’re getting really burnt out.
If you do that at an early-stage company enough times, either you’re successful with it and you become the founder, or you burn out.
Jenny, what are you seeing on the burnout side?
Lauri asked because I’d just published an article on burnout. (Part two came out after the panel.)
Jenny: The product manager job has always come with unrealistic expectations. Do product marketing, help with design, do the user research, work out business viability, get everybody on the same page, make sure engineering isn’t blocked, and keep everyone updated on status. That’s never been realistic.
Now we’re adding, “And can you also do a prototype? Just make it look nice.” And “Did you see the 10 things Anthropic released into Claude Code last week? Have you tried all of them yet?”
The PMs I work with are falling into two camps. One camp is retreating: “I’ll get to AI eventually. I’m too tired. If you don’t make this easy for me, I’m not doing it, because did you see what’s on my plate?”
The other camp is so scared of being left behind that they’re spending all their nights and weekends learning AI and learning to prototype.
Some of them are saying it’s the most fun they’ve ever had. Others are saying, “I miss my kids.”
Jake: Nights and weekends were the only way I got to where I am, in a position to lead teams through the transformation.
I tell people it’s like any other new skill. The gym is awkward when you first go. You build a routine, you get consistency, the muscle gets bigger.
But I get the other side 100%. I’ve done this for 20 years. I’ve learned 20 new tricks for the 20 years. I have two kids at home. I can’t do it nonstop.
Jason, have you had a client you had to rein in, where AI had convinced them they were more of an expert than they were?
Jason: I had a client who had coded a lot of the first version of their product and was really proud of it. We’re still working through building things a different way, so it isn’t going to fall apart because their version is built with spaghetti string and hopes and dreams.
What’s worked is helping them recognize where their talents and expertise really lie. “You can focus on that area. Don’t worry about the rest. I’ll bring in how companies typically do this.”
Jenny: That ties a few of these topics together. Jake, you described the PM who coded something that’s missing key usability and accessibility pieces, so your team has to rewrite it.
I’m hearing the same thing from engineers: product just handed me this prototype, and the code underneath is spaghetti string and hopes and dreams.
Someone in the audience said earlier that they used to solve coding problems and now just review AI’s output. Nobody becomes an engineer to spend all their time doing code review, and definitely not to spend it fixing somebody else’s hopes and dreams.
It also puts the other person in an awkward position. They’re thinking, “Can’t I just throw all your stuff away and start over? That would be easier.” But now there’s an interpersonal complication, and it feels weird to ask.
It gets worse with hierarchy. The executive codes a prototype over the weekend, hands it to an engineer, and says, “Isn’t this cool? Can we ship it?”
This is threatening people’s identities, the reasons they got into these jobs in the first place. That’s feeding the burnout, the burnout pulls people further apart, and the cycle keeps going.
From the audience: what about people pushing AI-built work to production before it’s ready?
An audience member asked about AI-built products that didn’t work out. Lauri sharpened it: everyone thinks they’re a coder now, so what happens when people push code to production that isn’t ready?
Jenny: One thing I’ve been working on with my teams is the term “throwaway prototype.” Instead of going to your engineer with “Hey, I made this prototype, what do you think?”, which forces them to look through the code, say “I made this throwaway prototype because I wanted to communicate this idea. What do you think?”
The adjective you put in front of “prototype” sets the scene for what the interaction is.
We don’t ship prototypes. We ship hardened products. But “prototype” standing on its own doesn’t tell anyone what you’re trying to learn.
Do you want to put it in front of users to test usability? Or, as I heard from a couple of PMs, did the engineer say something wasn’t possible in our system, so you got Claude to build it to show it’s feasible, and now you want their opinion on whether it’s a viable approach?
Those are completely different uses of a prototype.
Jake: Figma used to save us here. You were presenting a concept that was nowhere near code-ready, and the engineers got it: “This is a Figma. I’m the one who has to chop it up. I’m the one who makes the core decisions.”
Prototypes are meant to be just that. They can’t go into production. They test a theory.
From the audience: “The simple answer is more collaboration across the triad. What else gets us to a better future state, without piling up more technical debt?”
Jason: I’d love to talk with the frontier AI companies about how their interfaces could better support collaboration. I’ve been working on a client project in Claude Design. It’s very good at getting to a design you can click through and see whether it meets the need.
But when the client wants to make modifications or suggestions, it’s really hard to have the back and forth you used to have on a Miro board or a whiteboard. The tools don’t support that right now.
It’s still individuals working with their own instances of Claude. I haven’t found the silver bullet yet.
Jenny: The guideline I’m using right now is: wait for the other function to invite you in.
At the client I’m working with, design was getting really frustrated by all this. So I worked with them to put together a workshop for PMs on using Claude Design to make prototypes.
We specifically encouraged PMs not to prototype in the actual codebase. Instead: take a screenshot and work in Claude Design, using the design system the design team built and hooked up so you pull in the right components, with the guardrails design wants around it.
Another example: this company is short on data scientists, so they can’t respond to every request.
The data team built plugins with the data dictionary and instructions on which tables to use, so you can ask Claude in plain language, “How many users from the EU tried to access this feature last week?” That replaces “I wrote this SQL query, can you check it?”
You’re going into their territory on their terms, instead of going in on your terms.
From the audience: is any of this producing ROI?
Alex (audience): Moving faster with mid code or mid designs that ultimately get thrown away isn’t ROI. At a bigger company, ROI is reducing costs: fewer people, fewer tools.
At startup scale, there’s value in speed to MVP. But if you made it in a day, someone else can [copy] your startup in two seconds.
Three years in, I’m still asking ROI questions to a lot of leaders and getting mixed answers. Jake, are you hiring fewer people? Or are you telling the C-suite design brought in 3x the revenue?
Jake: We are seeing more productivity. The biggest ROI is in what used to be a handoff from a static Figma prototype. Now it’s working code using our design system components and our vetted layouts, and we’re doing code reviews, which helps engineering with the implementation.
There’s less design churn, because we’re giving engineers the components they would have been creating on their own, instead of “What font was that? What size was that?”
As far as staffing, we’re fairly flat. The hope is to do more with the people and the capacity we have.
Jason: What I’ve been hearing on podcasts is this idea of ambition, which I don’t think a lot of companies have figured out. Making existing tasks more efficient is the low-hanging fruit.
The harder part, with any technological innovation, AI included, is what more a designer, a product manager, and an engineer can now do together.
Startups are having an easier time seeing that. At larger companies, I don’t know if many have figured it out yet.
Jake: JumpCloud’s been around for 13-plus years. At companies at our stage or bigger, the CEOs and stakeholders all want the decrease in headcount and the increase in ARR. I don’t think they understand how far away the rest of the organization is from that.
Startups that began in the last few years built their code with AI, and AI loves AI-driven code. I could go in there without a lot of guardrails and crank out features.
In an environment that’s fragile, with a lot of dependencies, I cannot push to prod. I don’t want that accountability.
We saw that in the market last year with the huge cuts.
I knew people who got cut in those rounds, and I asked them, “Were you AI everywhere? Were you automating everything?” They said, “No, Jake. We weren’t anywhere near the efficiencies they said we were at.”
Lauri: So AI got the blame for a lot of headcount reduction last year.
From the audience: is engineering turning into a gatekeeper that just reviews AI-written code?
An audience member picked up on something Jake had said: his design team now writes working front-end code and hands it to engineering. Does that make engineering a gatekeeper to production, reviewing AI code that’s already been written?
Jake: Engineers are the gatekeepers. My team owns the front end. We don’t own the back-end logic or the dependencies, and we don’t have deep knowledge of all the APIs.
I wouldn’t even trust AI to push in the environment I work in. So engineering ties in the back-end business logic, and we test it, proof it, file bugs, and fix them. We’re not trying to venture into the back-end world at all.
Lauri: That’s especially true in legacy code, and most companies are legacy code.
Jenny: I’m the biggest advocate of engineering setting up systems that enable everybody else to ship code. But that’s engineering’s responsibility, engineering and QA.
When people ask what role to go into in tech right now, I’m excited about SREs, QA, SDETs, the people who think about code quality in a meaningful way.
What all these organizations need is agentic checks: proper test coverage, and real tests. I love when you tell AI the test fails, and it says, “Oh, I guess I’ll just change the test then.” (Cue the sarcasm.)
You want real coverage and AI-driven code review that knows when to say “this one needs a person to look at it” versus “this is a color change on a button, it’s all good.”
Right now the bottleneck is landing on “I made this, can you code review it?” It changes the conversation if everybody feels confident that engineering isn’t going to be the one left holding the bag when you vibe coded something.
Jake: We’re stepping into other people’s turf, and we need their help to tell us what’s right or wrong. That’s where strong partnerships come in.
If you have good engineers who are willing to take the time to educate, put the right guardrails in place, and be on call for questions and code reviews, the more they do it, the more you’ll see [companies like] Linear shipping end to end, regardless of a design role or a PM role.
But people miss that it took so much enablement, so much effort, so much partnership to get to the stage where it doesn’t fail every time.
Jenny: And what do you think, Riley? Should I be bullish on SDETs?
Riley: Evals are such a hot topic right now. Everyone is hiring for it. We’ve even heard of PMs at startups running evals.
And SRE, heavy back-end work, and security are top of mind in hiring, and a rarer skill set for us to find.
From the audience: do organizations need to change in a bigger way to get the most out of AI?
Jake: A traditional enterprise could have been super efficient: ARR going up, product-market fit, listening to customers.
AI came in as the largest curveball it could, and it’s completely unmeasurable at this point. We’re shipping a lot of features, and most of them are stable, but everybody knows more isn’t always better.
It’s created a false sense of urgency. We already had a sense of urgency, and now it has to be a true emergency all the time, at emergency pace.
Jason: I don’t think anybody really knows what future organizations are going to look like.
Big technological innovations tend to create new types of roles and new types of organizations. We don’t know what those are yet with AI.
Jenny: Figuring out how to use AI as a trio is a cultural change, and it’s being forced on us whether or not we want it. The big question is which direction we go.
Do we figure out collaboration patterns that work? Or do we end up with 20 solo builders as the entire product development team, each owning something in a silo?
I’m hearing the ratio question too. It used to be that one PM, four to six engineers, and one designer was the ideal team.
I’ve heard “just get rid of the PMs, it’s an engineer and a designer.” I’ve heard one to one to one. I’ve heard a PM plus an engineer, and, sorry design [to Jake], you’re the ones being squeezed out in the current discourse.
The companies trying to hold on to how they were before are the ones really struggling right now. That’s part of why this is so painful. The change is being forced on us.
Jake: The 20 silo builders is the thing that scares me. Everywhere I’ve built product, other people align to what you just built. You built a new service or a new API, and it pairs with this other thing.
When you hear it from Anthropic and the people shipping code on the train to work, they still haven’t shown us how they coordinate that much solo output at such a crazy rate.
If Jenny shipped something yesterday and Jason shipped something today, I’m already 20 features behind, and my feature should tie into what they just built. I don’t know how they’re doing it. You kind of wonder if it’s all just going to fall down.
Jason: Companies are based around humans. We built these structures not just because they’re the efficient way to run a business, but because we collaborate with other humans really well, and we like to do that.
Maybe in theory the most efficient way to build is to have one solo person in charge of everything. I don’t see evidence of that being realistic yet, and I doubt that’s where we end up. We’re still going to have organizations of people with different areas of expertise, working together to solve problems.
Lauri: And it works.
Jason: It has, for millennia.
RMAIIG posted a recording of the panel if you want to watch it.