20 Skills to Elevate as a Product Designer in 2026


Product building changed a ton in 2025: Designers are now expected to code, product managers want to do design, engineers now need to work with everyone’s (AI) sloppy prototypes, agents might eventually do all of it instead of on behalf of everyone else… I doubt 2026 will be any less exciting.

Given these changes, as someone who’s held a “product design” title for the last 6-7 years, here’s what I think is critical to focus on in 2026.

  1. Sense of taste. In the world right now, what’s generic and what’s special? And where are things heading? Machines can easily churn out the generic versions, so who’s breaking away, and what are they doing? And as an individual, what can you do that’s special yourself?
  2. Ability to distinguish between what needs to be generic and what needs to be special? It’s important to understand where generic is ok (or even preferred, like from a users perspective), and where it’s ok to over-invest in visual design, interaction details, content, and more.
  3. Ability to articulate a sense of taste and design overall. This has always been important as a design collaborator, but now it’s particularly valuable as an “individual contributor”. AI LLM tools are very good at transforming well articulated thoughts into specific outcomes, so the more this skill can be honed, the more you can make use of powerful tools. My hypothesis remains that most people can’t do this very well.
  4. Spend more time learning about nuances in design, programming, etc. LLMs excel at handling generic situations, and are able to translate that into tangible outputs in design, code, etc. But statistically, they must be less good at handling and understanding edge cases, small details, etc. In finance, this edge might be described as the “alpha”. So what’s the “alpha” in product design?
  5. Collaboration skills with product management. In 2025, product managers demonstrated that if they can create a prototype on behalf of instead of a designer, they will do it. Unfortunately, these designs and prototypes generally don’t go through the more rigorous process of reviews and critiques expected when designers create an artifact. Therefore, it’s on designers as presumed “taste-havers” and design experts to, at minimum, better analyze and challenge what PMs produce. We didn’t always do this effectively when that came to text-heavy product documents, but now that PRDs have become prototypes and requirements are being communicated visually, we have no excuse not to step-in. It’s important to do this tactfully though: don’t come from a place of insecurity. Approach the critiques like thought partners and coaches. You’re not training a replacement. You’re actually delegating and freeing your time for more important work (see below).
  6. Critical thinking on business needs. In general, product designers have long outsourced direct oversight of high-level business-related thinking and decision making to product managers. But now that product managers themselves are creating designs themselves, they’ll inevitably spend more time on the question of “what color should this button be” than they ever used to. This is an opportunity for product designers (who already know what color the button should be 😜) to instead invest their time and knowledge in higher-level problem solving.
  7. Delegation skills. For as long as I’ve been in the industry, it’s been rare for senior and principal designers to have junior designers handle work on their behalf. I think the world will desperately need a new form of “junior designers”, but in the meantime, designers actually have their own “work-doers” now: see Cursor, Figma, v0. With the ability to articulate properly (see above), these tools can in fact build 80-90% of pretty much whatever you want. So delegate! Yes, you can’t in fact go away for hours to focus on something else - these systems need hand-holding, and the designers that can dip into the details and handle edge cases with care will be the ones who stand-out. But in general, these systems will accomplish what you need in a fraction of the time it used to take. So invest those time savings in better activities (critical thinking, planning, communication etc.)
  8. Outward communication. In the past, designers have been able to point to their designs, prototypes, research work, and all sorts of other visual artifacts as “proof of value”. But now everyone can churn out pretty things! So how do we demonstrate our unique value now? Organize it. Show how it ties to business needs. Demonstrate how it’s not just generic “slop” but actually well considered for your actual user and customer needs. Move up the corporate stack. “Everyone is a designer now” is an opportunity, not a threat: while they’re out busy learning about and mesmerized by the basics, you’re proving an expert-level grasp of skills that everyone clearly values and wants to have, then elevating the discourse to a new level.
  9. Edge Case Creativity. New technologies can feel scary when they directly impact your job. But these tools are pretty fascinating. They may not be the world-altering powers that many people would like you to believe, but they really can empower you to experiment with new creations, ideas, and processes. Find special little problems in your world, and mess around with some of these tools to see what you make. Or play with more “IRL” experiences that have less corollary in software right now, and see how they might by interpreted, magnified, resolved by an LLM tool (or maybe do it just for fun…).
  10. Pull Requests. This is my desperate shot to get to 10 items, but I think the future of collaboration in product building will revolve around pull requests. PRs are already the centerpiece of engineering teamwork, and now that designers and product managers are being welcomed casting themselves into the world of code-first artifacts, I think we’re likely to see business context, design feedback, and more appear in Github. Cursor just acquired Graphite, so clearly I’m not the only on who thinks this. But I don’t think we need to wait to be invited into production code to do this. It’s something you can start to do with prototypes, analyses, and more. Could be a fun thing to show off in the meantime!

In 2027, I’ll look back and see if/how any of this was used, and what I missed.