In 2022, Airtable's product team had a challenge processing feedback from customers. After rapid growth from 150 to 700 employees, customer feedback was pouring in through Slack, email, support tickets, and sales calls. Nobody could make sense of it.

A cross-functional team built a solution: a centralised system that aggregated feedback from every channel. They launched it at their sales kickoff and got a standing ovation. Customer voices would finally drive the roadmap.

There was just one problem. It didn't work.

The system made submitting feedback so easy that volume exploded from dozens per week to thousands. Product managers were now drowning in triage. After a month, feedback was going into a black hole again - just a bigger one.

They had solved the problem perfectly. It was the wrong problem.

The Trap: Perfecting the Wrong Thing

Most careers follow a progression through levels of thinking.

At Level 1, your value is task execution, where you're given a specific task and you deliver a specific output. At Level 2, you graduate to solution design, where you're no longer just completing tasks; you're deciding how problems should be solved. There are always multiple approaches; the skill is knowing which fits the situation.

AI is reshaping both levels simultaneously.

Level 1 is being automated. The research synthesis that took a week? Done in minutes. The competitive analysis, the user interview summaries, the front-end fixes - AI handles them now.

Level 2 is facing new pressure. Solving the wrong problem was never valuable, but slow delivery used to provide cover. "We're still building it." "It's too early to tell." The slow pace of execution created a buffer between effort and accountability. Now that the buffer is gone. When you can ship in weeks what used to take quarters, you reach "did this actually work?" much faster. There's nowhere to hide.

The instinct when facing a problem is to ask, "How do I solve this better?" But often the challenge is that you are solving the wrong problem in the first place. Instead of focusing on the best way to build a solution, you need to challenge the problem itself.

Outcomes Require You to Leave Your Functional Home

Here's the uncomfortable truth about shifting from solutions to problems: it requires you to leave your functional home.

Outcomes don't live inside functions. Retention isn't a design problem or an engineering problem - it's both, plus marketing, plus customer success, plus pricing. Churn might initially look like a product issue, but the most effective solution could involve redesigning onboarding flows, adjusting pricing tiers, and refining customer success touchpoints simultaneously.

When you only see your piece of the puzzle, you optimise your piece. But customers don't experience your function - they experience the product. And the product is shaped by every function at once.

This is where the classic "T-shaped professional" model breaks down. The old advice was to go deep in one area and stay shallow everywhere else. But AI has made deep expertise abundant. You can prompt your way to a competent first draft in almost any domain. Yes, expertise in the area will help you determine if the output is high quality or not, but AIs are consistently improving, and the quality bar of outputs keeps rising.

The scarce skill now isn't depth - it's connection. Seeing how problems link across domains. Understanding why engineering is pushing back on what seems like a simple design request. Recognising when a product decision will create a nightmare for the sales team.

You don't need to become an expert in every discipline. But you do need enough understanding across disciplines to see the system as a whole and identify where effort will actually have impact.

The Comb-Shaped Professional

If T-shaped isn't enough, what's the alternative? Think of it as comb-shaped: moderate depth across multiple disciplines, with the ability to see how they interact and influence outcomes.

A comb-shaped professional can sit in a room with engineering, design, research, and marketing - and follow the conversation in each domain well enough to spot where they're talking past each other. They can trace a customer problem through multiple functions and identify which combination of changes will actually solve it.

Building this doesn't require going back to school. It requires intentional exposure.

Learn what each function optimises for. 
Engineering cares about maintainability and system reliability. Design cares about user experience and coherence. Sales cares about closing deals. Finance cares about margins. When you understand what someone is optimising for, their decisions stop seeming arbitrary and start making sense within their context.

Ask experts to explain their reasoning, not just their conclusions. 
When a designer says, "This flow doesn't work" or an engineer says, "That's a six-month rewrite" don't just accept it. Ask them to walk you through how they got there. What are they seeing that you're not? This is how you absorb cross-functional judgment, not just cross-functional information.

Take on projects that force coordination.
Volunteer for initiatives that span teams. These are uncomfortable because you'll be out of your depth in at least one area. That discomfort is the learning. You'll discover which questions to ask, which assumptions to challenge, and where functions typically misunderstand each other.

Putting It Into Practice: Aligning People Around Problems, Not Solutions

Seeing the whole board is one thing. Getting people to move together is another.

The challenge at this level is aligning people who don't report to you, who have competing priorities, and who measure success differently. You have no authority. You're asking them to prioritise your framing of the problem over their own. And you're doing it across functional boundaries where incentives, vocabularies, and success metrics all differ.

Two approaches help:

Translate across vocabularies
Different functions use different words for overlapping concepts. They have different instinctive reactions to risk and ambiguity. Part of your value comes from being a translator - explaining to engineering why design is pushing back, helping design understand the technical constraints, framing the problem in terms that finance cares about, and in terms that customer success cares about.

This isn't manipulation. It's recognising that alignment requires people to see how the shared goal connects to what they already value.

Make the problem visible, not your solution
People align more easily around a well-framed problem than around a proposed solution. When you're trying to build cross-functional alignment, invest in making the problem undeniable.

Bring data. Bring customer quotes. Bring the support tickets, the churn analysis, and the usability test clips. Make it impossible to look away from the problem. Then invite people to solve it together rather than presenting your solution and asking for buy-in.

When people feel ownership over the diagnosis, they're far more likely to commit to the treatment.

The Airtable Resolution

Back to Airtable. After their feedback system failed, they didn't optimise the triage process. They questioned the problem itself.

Instead of asking "How can AI help us triage faster?" they asked: "Why are we triaging at all? What outcome are we actually trying to achieve?"

The answer wasn't "processed feedback." As their VP of Product Management, Anthony Maggio, put it: "The goal was never to categorise every submission. It was to surface patterns that inform strategy."

That reframe changed everything. Instead of optimising triage, they automated it entirely. AI now categorises, tags, matches to roadmap items, and surfaces trends. Product managers stopped reviewing individual submissions and started receiving proactive alerts about emerging patterns.

The result: a 20% increase in features shipped over two quarters. And this was all down to diagnosing which problems actually mattered.

The standing ovation was for the wrong solution. The real win came from questioning whether the problem was right.

The Shift That Matters

This shift asks you to hold your functional identity more lightly. You still need functional depth to have credibility. But you can't let it limit what you're willing to see. The product manager who only thinks about the product will miss the organisational dynamics blocking progress. The designer who only thinks about design will optimise screens while the business model collapses.

The professionals who make this transition learn to see themselves as problem-solvers first, specialists second.

This is where humans still win. AI excels at individual tasks within boundaries. It struggles to connect insights across disciplines, to see how a design decision affects engineering capacity, how a pricing change impacts customer success workload, how a product bet reshapes the sales conversation.

Connecting the silos - that's the job now. And it starts with being willing to question whether you're solving the right problem in the first place.

This is the fifth article in a series exploring how AI is reshaping career progression. The next article examines how to manage the shift from a focus on outputs to a focus on outcomes. If you want to go deeper, check out our free ebook: Managing your Career in the Age of AI.