The data from Lenny’s Newsletter’s AI productivity survey showed PMs ranking prototyping as their #2 use case for AI, ahead of designers. Here’s what that looks like in practice.

Figma is now teaching PMs to build prototypes instead of writing PRDs. Using Figma Make, product managers can go from idea to interactive prototype without waiting on design. Emma Webster writing in Figma’s blog:

By turning early directions into interactive, high-fidelity prototypes, you can more easily explore multiple concepts and take ideas further. Instead of spending time writing documentation that may not capture the nuances of a product, prototypes enable you to show, rather than tell.

The piece walks through how Figma’s own PMs use Make for exploration, validation, and decision-making. One PM prototyped a feature flow and ran five user interviews—all within two days. Another used it to workshop scrolling behavior options that were “almost impossible to describe” in words.

The closing is direct about what this means for roles:

In this new landscape, the PMs who thrive will be those who embrace real-time iteration, moving fluidly across traditional role boundaries.

“Traditional role boundaries” being design’s territory.

This isn’t a threat if designers are already operating upstream—defining what to build, not just how it looks. But if your value proposition is “I make the mockups,” PMs now have tools to do that themselves.

The optimistic case for designers in an AI-driven world is that design becomes strategy—defining what to build, not just how it looks. But are designers actually making that shift?

Noam Segal and Lenny Rachitsky, writing for Lenny’s Newsletter, share results from a survey of 1,750 tech workers. The headline is that AI is “overdelivering”—55% say it exceeded expectations, and most report saving at least half a day per week. But the findings by role tell a different story for designers:

Designers are seeing the fewest benefits. Only 45% report a positive ROI (compared with 78% of founders), and 31% report that AI has fallen below expectations, triple the rate among founders.

Meanwhile, founders are using AI to think—for decision support, product ideation, and strategy. They treat it as a thought partner, not a production tool. And product managers are building prototypes themselves:

Compare prototyping: PMs have it at #2 (19.8%), while designers have it at #4 (13.2%). AI is unlocking skills for PMs outside of their core work, whereas designers aren’t seeing the marginal improvement benefits from AI doing their core work.

The survey found that AI helps designers with work around design—research synthesis, copy, ideation—but visual design ranks #8 at just 3.3%. As Segal puts it:

AI is helping designers with everything around design, but pushing pixels remains stubbornly human.

This is the gap. The strategic future is available, but designers aren’t capturing it at the same rate as other roles. The question is why—and what to do about it.

It’s January and by now millions of us have made resolutions and probably broken them already. The second Friday of January is known as “Quitter’s Day.”

OKRs—objectives and key results—are a method for businesses to set and align company goals. The objective is your goal and the KRs are the ways to reach your goals. Venture capitalist John Doerr learned about OKRs while working at Intel, brought it to Google, and later became the framework’s leading evangelist.

Christina Wodtke talks about how to use OKRs for your personal life, and maybe as a way to come up with better New Year’s resolutions. She looked at her past three years of personal OKRs:

Looking at the pattern laid out in front of me, I finally saw what I’d been missing. My problem wasn’t work-life balance. My problem was that I didn’t like the kind of work I was doing.

The key results kept failing because the objective was wrong. It wasn’t about balance. It was about joy.

This is the second thing key results do for you: when they consistently fail, they’re telling you something. Not that you lack discipline—that you might be chasing the wrong goal entirely.

And I love Wodtke’s line here: “New Year’s resolutions fail because they’re wishes, not plans.“ She continues:

They fail because “eat better” and “be healthier” and “find balance” are too vague to act on and too fuzzy to measure.

Key results fix this. Not because measurement is magic, but because the act of measuring forces clarity. It makes you confront what you actually want. And sometimes, when the data piles up, it reveals that what you wanted wasn’t the thing you needed at all.

Building on our earlier link about measuring the impact of features, how can we keep track of the overall health of the product? That’s where a North Star Metric comes in.

Julia Sholtz writes and introduction to North Star Metrics in the analytics provider Amplitude’s blog:

Your North Star Metric should be the key measure of success for your company’s product team. It defines the relationship between the customer problems your product team is trying to solve and the revenue you aim to generate by doing so.

How is it done? The first step is to figure out the “game” your business is playing: how your business engages with customers:

1. The Attention Game: How much time are your customers willing to spend in your product?
2. The Transaction Game: How many transactions does your user make on your platform?
3. The Productivity Game: How efficiently and effectively can someone get their work done in your product?

They have a whole resource section on this topic that’s worth exploring.

How do we know what we designed is working as intended? We measure. Vitaly Friedman shares something called the TARS framework to measure the impact of features.

We need UX metrics to understand and improve user experience. What I love most about TARS is that it’s a neat way to connect customers’ usage and customers’ experience with relevant product metrics.

Here’s TARS in a nutshell:

• Target Audience (%): Measures the percentage of all product users who have the specific problem that a feature aims to solve.
• Adoption (%): Tracks the percentage of the target audience that successfully and meaningfully engages with the feature.
• Retention (%): Assesses how many users who adopted the feature continue to use it repeatedly over time.
• Satisfaction Score (CES): Gauges the level of satisfaction, specifically how easy it was for retained users to solve their problem after using the feature.

Friedman has more details in the article, including how to use TARS to measure how well a feature is performing for your intended target audience.

I really appreciate the perspective of Lai-Jing Chu here as a Silicon Valley veteran. The struggle to prove the value of design is real.

I don’t know another function or role in the tech industry where it seems like we have to do our jobs at the same time as — and I will avoid saying “demonstrating value” here because it’s more than that — we carry out some sort of divine duty to make the product (let alone the world) a better place through our creativity.

Instead of more numbers like ROI calculations, Chu argues for counterintuitive approaches for advocacy, “not more left-brain exercises.”

Chu introduces us to W. Edwards Deming, an influential management consultant who wrote:

The most important figures needed for management of any organization are unknown and unknowable, but successful management must nevertheless take account of them.

One strategy she offers is to ask leadership a common-sense question: How would you grade the design?

Because when was the last time anyone did the most basic thing — to stop for a moment, hold the product in their hands, and take a good hard look at it? These questions throw the ball back in their court. It makes them wonder what they can do to help. Because chances are, most leaders want their product to have a good user or customer experience and understand that it makes a difference to their business success. You don’t just want buy-in — you want them to have true ownership.

I admire this approach, because chances are, leaders are already hearing about UX issues from customers. But to put this into practice in, let’s say, at any startup post-Series A will be an issue. There’s a lot of coordination and alignment that needs to happen because exec-level attention is much harder to come by.

Here is a good reminder from B. Prendergast to “stop asking users what they want—and start watching what they do.”

Asking people what they want is one of the most natural instincts in product work. Surveys, interviews, and feature wish lists feel accessible, social, and collaborative. They open channels to understand and empathise with the user base. They help teams feel closer to the people they serve. For teams under pressure, a stack of opinions can feel like solid data.

But this breaks when we compare what users say to what they actually do (say-do gap).

We all want to present ourselves a certain way. We want to seem more competent than confused (social desirability bias). Our memories can be fuzzy, especially about routine tasks (recall bias). Standards for what feels “easy” or “intuitive” can vary wildly between people (reference bias).

And of course, as soon as we start to ask users to imagine what they’d want, they’ll solve based on their personal experiences—which might be the right solution for them, but might not be for other users in the same situation.

Prendergast goes on to suggest “watch what people do, measure what matters, and use what they say to add context.” This approach involves watching user interactions, analyzing real behaviors through analytics, and treating feature requests as signals of underlying problems to uncover genuine needs. Prioritizing decisions based on observed patterns and desired outcomes leads to more effective solutions than relying on user opinions alone.

Product manager Adrian Raudaschl offered some reflections on 2025 from his point of view. It’s a mixture of life advice, product recommendations, and thoughts about the future of tech work.

The first quote I’ll pull out is this one, about creativity and AI:

Ultimately, if we fail to maintain active engagement with the creative process and merely delegate tasks to AI without reflection, there is a risk that delegation becomes abdication of responsibility and authorship.

”Active engagement” with the tasks that we delegate to AI. This reminds me of the humble machines argument by Dr. Maya Ackerman.

On vibe coding:

The most important thing, I think, that most people in knowledge work should be doing is learning to vibe code. Vibe code anything: a diary, a picture book for your mum, a fan page for your local farm. Anything. It’s not about learning to code, but rather appreciating how much more we could do with machines than before. This is what I mean about the generalist product manager: being able to prototype, test, and build without being held back by technical constraints.

I concur 100%. Even if you don’t think you’re a developer, even if you don’t quite understand code, vibe coding something will be illuminating. I think it’s different than asking ChatGPT for a bolognese sauce recipe or how to change a tire. Building something that will instantly run on your computer and seeing the adjustments made in real-time from your plain English prompts is very cool and gives you a glimpse into how LLMs problem-solve.

AI threatens to let product teams ship faster. Faster PRDs, faster designs, and faster code. But going too fast can often lead to incurring design and tech debt, or even worse, shipping the wrong thing.

Anton Sten sagely warns:

The biggest pattern I have seen across startups is that skipping clarity never saves time. It costs time. The fastest teams are not the ones shipping the most. They are the ones who understand why they are shipping. That is the difference between moving for the sake of movement and moving with purpose. It is the difference between speed and true velocity.

How do you avoid this? Sten:

The reset is simple and almost always effective. Before building anything, pause long enough to ask, “What problem am I solving, and for whom?” It sounds basic, but this question forces alignment. It replaces assumptions with clarity and shifts attention back to the user instead of internal preferences. When teams do this consistently, the entire atmosphere changes. Decisions become easier. Roadmaps make more sense. People contribute more of themselves. You can feel momentum return.

Imagine working for seven years designing the prototyping features at Figma and then seeing GPT-4 and realizing what AI can soon do in the future. That’s the story of Figma designer–turned–product manager Nikolas Klein. He shares his journey via a lovely illustrated comic—Webtoon style.

Klein emphasizes:

The truth is: There will always be new problems to solve. New ideas to take further. Even with AI, hard problems are still hard. An answer may come faster, but it’s not always right.

We’ve been hearing a lot about AI agents and now enough time has passed that we’re starting to see some learnings in industry. Writing in Harvard Business Review, Linda Mantia, Surojit Chatterjee and Vivian S. Lee showcase three case studies of enterprises that have deployed AI agents.

They write about Hitachi Digital and how they deployed an AI agent as the first responder to the 90,000 questions employees send to their HR team annually.

Every year, employees put over 90,000 questions about everything from travel policies and remote work to training and IT support to the company’s HR team of 120 human responders. Answering these queries can be difficult, in part because of Hitachi’s complex infrastructure of over 20 systems of record, including multiple disparate HR systems, various payroll providers, and different IT environments.

Their system, called “Skye,” is actually a system of agents, coordinating with one another and firing off queries depending on the intent and task.

For example, the intent classifier agent sends a simple policy question like “What are allowed expenses for traveling overseas?” or “Does this holiday count in paid time off?” to a file search and respond agent, which provides immediate answers by examining the right knowledge base given the employee’s position and organization. A document generation agent can create employee verification letters (which verify individuals’ employment status) in seconds, with an option for human approval. When an employee files a request for vacation, the leave management agent uses the appropriate HR management system based on its understanding of the user’s identity, completes the necessary forms, waits for the approval of the employee’s manager, and reports back to the employee.

The authors see three essential imperatives when designing and deploying AI agents into companies.

1. Design around outcomes and appoint accountable mission owners. Companies need to stop organizing around internal functions and start building teams around actual customer outcomes—which means putting someone in charge of the whole journey, not just pieces of it.
2. Unlock data silos and clarify the business logic. Your data doesn’t need to be perfect or centralized, but you do need to map out how work actually gets done so AI agents know where to find things and what decisions to make.
3. Develop the leaders and guardrails that intelligent systems require. You can’t just drop AI agents into your org and hope for the best—leaders need to understand how these systems work, build trust with their teams, and put real governance in place to keep things on track.

Matt Ström-Awn makes the argument that companies can achieve sustainable excellence by empowering everyone at each level to take ownership of quality, rather than relying solely on top-down mandates or standardized procedures.

But more and more I’ve come to believe that quality isn’t a slogan, a program, or a scorecard. It’s a promise kept at the edge by the people doing the work. And, ideally, quality is fundamental to the product itself, where users can judge it without our permission. That’s the shift we need: away from heroics at the center, toward systems that make quality inevitable.

The stakes are high. Centralized quality — slogans, KPIs, executive decrees — can produce positive results, but it’s brittle. Decentralized quality — continuous feedback, distributed ownership, emergent standards — builds resilience. In this essay, I’d like to make the case that the future belongs to those who can decentralize their mindset and approach to quality.

Ström-Awn offers multiple case studies, contrasting centralized systems with decentralized ones, using Ford, Amazon, Apple, Toyota, Netflix, 3M, Morning Star, W.L. Gore, Valve, Barnes & Noble, and Microsoft under Satya Nadella as examples.

These stories share a common thread: organizations that trusted their frontline workers to identify and solve quality problems. But decentralized quality has its own vulnerabilities. Valve’s radical structure has been criticized for creating informal power hierarchies and making it difficult to coordinate large projects. Some ex-employees describe a “high school clique” atmosphere where popular workers accumulate influence while others struggle. Without traditional management oversight, initiatives can moulder, or veer in directions that don’t serve broader company goals.

Still, these examples show a different path for achieving quality, where excellence is defined in the course of building a product. Unlike centralized approaches relying on visionary (but fallible) leaders, decentralized systems are resilient to individual failures, adaptable to change, and empowering to builders. The andon cord, the rolling desk, and the local bookstore manager each represent a small bet on human judgment over institutional control. Those bets look like they’re paying off.

OK, so there’s workslop, but there’s also general AI slop. With OpenAI’s recent launch of the Sora app, there going to be more and more AI-generated image and video content making the rounds. I do believe that there’s a place for using AI to generate imagery. It can be done well (see Christian Haas’s “AI Jobs”). Or not.

Casey Newton, writing in his Platformer newsletter:

In Sora we find the entire debate over AI-generated media in miniature. On one hand, the content now widely derided as “slop” continually receives brickbats on social media, in blog posts and in YouTube comments. And on the other, some AI-generated material is generating millions of views — presumably not all from people who are hate-watching it.

As the content on the internet is increasingly AI-generated, platforms will need to balance how much of it they let in, lest the overall quality drops.

As Sarah Perez noted at TechCrunch, Pinterest has come under fire from its user base all year for a perceived decline in quality of the service as the percentage of slop there increases. Many people use the service to find real objects they can buy and use; the more that those objects are replaced with AI fantasies, the worse Pinterest becomes for them.

Like most platforms, Pinterest sees little value in banning slop altogether. After all, some people enjoy looking at fantastical AI creations. At the same time, its success depends in some part on creators believing that there is value in populating the site with authentic photos and videos. The more that Pinterest’s various surfaces are dominated by slop, the less motivated traditional creators may be to post there.

When I read this, I thought to myself, “Geez, this is what a designer does.” I think there is a lot of overlap between what we do as product designers and what product managers do. One critical one—in my opinion, and why we’re calling ourselves product designers—is product sense. Product sense is the skill of finding real user needs and creating solutions that have impact.

So I think people can read this with two lenses:

• If you’re a designer who executes the assignments you’re given, jumping into Figma right away, read this to be more well-rounded and understand the why of what you’re making.
• If you’re a designer who spends 80% of your time questioning everything and defining the problem, and only 20% of your time in Figma, read this to see how much overlap you actually have with a PM.

BTW, if you’re in the first bucket, I highly encourage you to gain the skills necessary to migrate to the second bucket.

While designers often stay on top of visual design trends or the latest best practices from NNG, Jules Walter suggests an even wider aperture. Writing in Lenny’s Newsletter:

Another practice for developing creativity is to spend time learning about emerging trends in technology, society, and regulations. Changes in the industry create opportunities for launching new products that can address user needs in new ways. As a PM, you want to understand what’s possible in your domain in order to come up with creative solutions.

The headline rings true to me because that’s what I look for in designers and how I run my team. The software that we build is too complex and too mission-critical for designers to vibe-code—at least given today’s tooling. But each one of the designers on my team can fill in for a PM when they’re on vacation.

Kai Wong, writing in UX Collective:

One thing I’ve learned, talking with 15 design leaders (and one CEO), is that a ‘designer who codes’ may look appealing, but a ‘designer who understands business’ is far more valuable and more challenging to replace.

You already possess the core skill that makes this transition possible: the ability to understand users with systematic observation and thoughtful questioning.

The only difference, now, is learning to apply that same methodology to understand your business.

Strategic thinking doesn’t require fancy degrees (although it may sometimes help).

Ask strategic questions about business goals. Understand how to balance user and business needs. Frame your design decisions in terms of measurable business impact.

Miquad Jaffer, a product leader at OpenAI shares his 4D method on how to build AI products that users want. In summary, it’s…

• Discover: Find and prioritize real user pain points and friction in daily workflows.
• Design: Make AI features invisible and trustworthy, fitting naturally into users’ existing habits.
• Develop: Build AI systematically, with robust evaluation and clear plans for failures or edge cases.
• Deploy: Treat each first use like a product launch, ensuring instant value and building user trust quickly.

This post has been swimming in my head since I read it. Elena Verna, who joined Lovable just over a month ago to lead marketing and growth, writing in her newsletter, observes that everyone at the company is an AI-native employee. “An AI-native employee isn’t someone who ‘uses AI.’ It’s someone who defaults to AI,” she says.

On how they ship product:

Here, when someone wants to build something (anything) - from internal tools, to marketing pages, to writing production code - they turn to AI and… build it. That’s it.

No headcount asks. No project briefs. No handoffs. Just action.

At Lovable, we’re mostly building with… Lovable. Our Shipped site is built on Lovable. I’m wrapping hackathon sponsorship intake form in Lovable as we speak. Internal tools like credit giveaways and influencer management? Also Lovable (soon to be shared in our community projects so ya’ll can remix them too). On top of that, engineering is using AI extensively to ship code fast (we don’t even really have Product Managers, so our engineers act as them).

I’ve been hearing about more and more companies operating this way. Crazy time to be alive.

More on this topic in a future long-form post.

In a dual profile, Ben Blumenrose spotlights Phil Vander Broek—whose startup Dopt was acquired last year by Airtable—and Filip Skrzesinski—who is currently working on Subframe—in the Designer Founders newsletter.

One of the lessons Vander Broek learned was to not interview customers just to validate an idea. Interview them to get the idea first. In other words, discover the pain points:

They ran 60+ interviews in three waves. The first 20 conversations with product and growth leaders surfaced a shared pain point: driving user adoption was painfully hard, and existing tools felt bolted on. The next 20 calls helped shape a potential solution through mockups and prototypes—one engineer was so interested he volunteered for weekly co-design sessions. A final batch of 20 calls confirmed their ideal customer was engineers, not PMs.

As for Skrzesinski, he’s learning that being a startup founder isn’t about building the product—it’s about building a business:

But here’s Filip’s counterintuitive advice: “Don’t start a company because you love designing products. Do it in spite of that.”

“You won’t be designing in the traditional sense—you’ll be designing the company’s DNA,” he explains. “It’s the invisible work: how you organize, how you think, how you make decisions. How it feels to work there, to use what you’re making, to believe in it.”

Brian Balfour, writing for the Reforge blog:

Speed isn’t just about shipping faster, it’s about accelerating your entire learning metabolism. The critical metric isn’t feature velocity but rather your speed through the complete Insight → Act → Learn loop. This distinction separates products that compound advantages from those that compound technical debt.

The point being that now with AI, product teams are shipping faster. And those who aren’t might get lapped (to use an F1 phrase).

Great reminder from Kai Wong about getting stuck on a solution too early:

Imagine this: the Product Manager has a vision of a design solution based on some requirements and voices it to the team. They say, “I want a table that allows us to check statuses of 100 devices at once.”

You don’t say anything, so that sets the anchor of a design solution as “a table with a bunch of devices and statuses.”

Nate Jones performed a yeoman’s job of summarizing Mary Meeker’s 340-slide deck on AI trends, the “2025 Technology as Innovation (TAI) Report.” For those of you who don’t know, Mary Meeker is a famed technology analyst and investor known for her insightful reports on tech industry trends. For the longest time, as an analyst at Kleiner Perkins, she published the Internet Trends report. And she was always prescient.

Half of Jones’ post is the summary, while the other half is how the report applies to product teams. The whole thing is worth 27 minutes of your time, especially if you work in software.