How to understand a company’s product approach before you join

The key questions to ask during the interview process

One of the most influential aspects of any company’s culture is their approach to making decisions. While this can be very general—and applies to all sorts of decisions from who to hire to what projects to staff to what the company apparel looks like—it’s the sort of thing that can directly impact your experience working at the company. We often meet people surprised to learn that they joined a company and particularly a founder that really does not care about their department or division (e.g. “marketing can just live on an island while the rest of the company focuses on the important engineering problems”). We would like to help you avoid this situation, and so we brought in an expert: Jori Bell.

Jori Bell is a seasoned product leader & coach with extensive experience launching & scaling 0-1 products to millions at companies including Audible, Spotify, SoundCloud, Rolling Stone, and AOL. Jori works with product leads and their teams to deliver high impact products using the product operating model. Jori hosts monthly breakfasts for Product Leaders, writes Product Therapy and supports fellow coaches through her community, Coaching Corner. And Jori is, as you’ll read throughout this essay, an amazingly qualified person to give you tactics to “Understand a Company’s Product Approach Before You Join.”

Months after I left my role as a Product Director at Audible, I came across data that validated the feels I’d been feeling. In December 2023, a CNBC article reported that Senior Product Manager ranked as the top job people want to quit, despite a $144k median salary.

“Yep, that tracks,” I thought.

After 12+ years as a PM at companies like Audible, Spotify, and SoundCloud, I needed something different too.

So, I pivoted to product coaching to exercise my product chops in a totally different way. As I coached dozens of PMs across levels and industries, a recurring theme emerged: PMs were all struggling with their company’s product culture.

This was especially pronounced among my clients that were seeking new roles. They aspired to join product-led organizations but struggled to thoroughly evaluate companies, often landing them in disappointing new roles.

Over time, I discovered specific questions that helped job seekers more effectively assess a company’s culture before they joined. In this post, I’ll share these questions to help you better assess a company’s product culture before signing an offer letter.

1. I’ll start by exploring what’s happening with product today (from “Why are so many people are leaving product?” to “Is AI killing product?”)

2. Then, I’ll define what a product-led culture means (spoiler: it’s not all about product)

3. Finally, I’ll share specific questions to vet a company’s product culture—so that your next career move is the right one.

What’s Going On with Product Today?

Aside from the 2023 survey, I’m very privy to the qualitative challenges of PMs today. As I’ve met hundreds of product people around the world, certain themes remain wherever I go:

• Product is completely misunderstood at my company.

• Product is an unsustainable career path.

• My company says we’re product-led, but we are so far from it.

Couple that with the “product is dead” mantra and big companies are “killing” product management and it makes sense why it can feel bleak to be a PM right now. It’s why many people are leaving altogether.

The reality is that the product role can feel unsustainable for many reasons. While it's tempting to point to broad trends—like AI—as the cause, much of it comes down to personal and situational factors. That said, one thing remains consistent: the happiest PMs I encounter are those who have found themselves in true product-led organizations.

But sadly, these are rare.

Too often, I hear stories of PMs misreading interview signals and landing in product roles where the culture didn’t meet their expectations. And in many cases, it was way off.

So, over time, I’ve documented what sets PMs apart when they land in the right places. Things like the questions they ask and the outcomes that follow.

My hope is to help you better grasp what a product-led culture really looks like. I have a good sense of what it feels like, not just because I got to live it, but because as a Product Coach, I have a better perspective than I ever did before.

With that, let’s look at what it means to work in a product-led culture.

What Does a Product-Led Culture Really Mean?

Product-led culture is tricky because it, by name, it privileges the product function. Being product-led doesn’t mean putting product people in charge; it means putting the customer in charge and matching that with business viability.

Product-Led Means Customer-Led

Putting the customer in charge means solving real world problems.

It means when I ask about your company, you can clearly tell me who you’re building for and what problem you’re solving. Watch this:

When a company centers their customer rather than their enabling technology, it’s not just good for PMs—it’s good for design and engineering. It’s also fantastic for sales, and ultimately, the business.

A customer centric leader

To be clear, a product-led company doesn’t need a leader with a product background.

What the leader must have is an understanding of the product role and a sense of the value PMs bring to the organization. Product-led leaders know that PMs own more than the roadmap. They own the vision, the strategy and the work that falls underneath it. If your leaders don’t understand the PM role and how important it is for PMs to talk to customers, you’re dead in the water.

This disconnect—a leader not understanding the product role—is a root cause of why the role often feels unsustainable. PMs aren’t just doing their role, they’re constantly educating others on what it is and why it’s valuable. It’s exhausting.

As Marty Cagan articulates best, true product-led organizations are distinct in how they operate. Specifically in how they build and deploy, how they solve problems and how they decide which problems to solve. To go a level deeper:

How You Build and Deploy matters. Continuous delivery processes are table stakes. It’s the difference between big bang, high-stakes releases and shipping new value every two weeks so that your team can place better bets to move the business forward quickly.

How You Solve Problems is paramount. Product teams (i.e. product, design, engineering) are given problems to solve not stakeholder-defined features to build. It’s the difference between “Can you solve why drivers aren’t finding their riders?”and “Can you build this button on the maps page?”

How You Decide Which Problems to Solve is the most indicative of a healthy product-led culture. A strong product-led company allows good ideas to come from anywhere but has a rigorous way of deciding which ideas to move on. It’s the difference between problems that come from the C-Suite and problems that come from customers.

The way a company answers these questions will tell you a lot about the culture.

But what happens when you’re yet to join the company?

How Do You Find a Product-Led Company?

In theory, companies and hiring managers will say they’re doing it right. They’re trained to attract really great talent.

But, how do you really vet how things are happening at a company before you sign an offer letter? How do you really know what the culture is like once you step inside, especially without an insider POV?

Let’s break down how you might better vet a culture using Marty’s framework.

Ask How Teams Build

In the spirit of continuous delivery, this one is really the most straightforward. Specific questions can quickly tell you how customer centric and thus product-led the organization really is.

Questions to ask:

1) How often does the team interact with customers and who gets to talk to customers?

Regular and direct customer interaction ensures teams stay grounded in real problems and build solutions that matter. If you’re relying on second-hand customer data only, you’re missing the mark. Further, empowering cross-functional teams to engage with customers strengthens your operation. Limiting customer interactions to a single role creates information silos.

And believe me, silos never work.

🟢A Great Answer:

"Customer interaction is built into our workflow. We incorporate insights from customer success, support, and sales alongside direct engagement with customers. While product and UX teams lead, we encourage engineers and others to join these sessions to build empathy."

Automated customer engagement is the best of the best. Here’s an example of what this looks like: Years ago, I built a product that had a form. At the end of the form, we asked customers to complete a survey. Throughout the week, anytime customers used the form, I’d reach out to the customer over email to learn more. It was built into my workflow. And when emails needed a follow up call, I’d often invite a designer or engineer to join. No formal interviews required.

🟡A Good Answer

"Our team interacts with customers monthly. We prioritize direct feedback through interviews and usability testing. We let our engineers and stakeholders listen to the recordings after."

Customer engagement doesn’t have to take one form. But cadence is important. A team that’s talking to customers regularly is a team that knows how to represent customer needs the best. Build a habit and stick to it. And do one better than sharing a recording. If your engineers or stakeholders can’t be in the room, let them listen in live and allow them to offer follow up questions to ask customers.

🔴A Bad Answer:

"We rarely talk to customers. It’s more of a quarterly activity when we run surveys or review feedback from support tickets. It’s mainly customer success that gets to chat with customers. We’re focused on building, not talking to customers."

Yikes. So many red flags here. Beyond an infrequent cadence, blocked customer access is one of the biggest red flags you can spo. If you don’t have direct access to customers, or if there’s not a plan to change that, run for the hills.

2) How often do you release to your customers? What does testing and experimentation look like?

Frequent, iterative releases enable teams to deliver value continuously to learn quickly. Long, infrequent release cycles are risky and costly. In asking about release cycles, you’ll also uncover if there’s a culture of experimentation. Look for a culture of experimentation.

🟢A Great Answer:

"We release in small, iterative increments, typically weekly or bi-weekly. This allows us to gather feedback, address issues, and continuously improve. We’re constantly experimenting and want our customers to quickly adapt so we usually have dozens of A/B tests running at a time.”

Weekly releases and concurrent experiments is a sign of a healthy continuous delivery team. Teams that have a weekly handle on their release and experimentation process are derisking and delivering value quicker. That’s not to say you should release for the sake of releasing or experiment for the sake of experimenting. But, strengthening the release muscle makes for a stronger team and ultimately better products.

🟡A Good Answer:

"It depends on the nature of the feature, but we aim for monthly releases. We have a mix of qualitative and quantitative running experiments, but not with regularity.”

Sure, different features can have different cadences. But, a team that’s not breaking down big features into smaller pieces and releasing those regularly is concerning. Why? Because a team that doesn’t know how to break down work runs the risk of wading into big bang release territory. While there’s a time and a place for a big bang release, it shouldn’t be the norm. Same goes with experiments. If they can’t name the last experiment they ran, it’s a red flag.

🔴A Bad Answer:

"We release in big batches every six months to ensure everything is perfect. We test features after they’ve been built, but experimentation isn’t a part of our workflow—it’s more about catching bugs."

Like I said, there’s a time and a place for a big bang release, but waiting until everything is perfect is a dangerous trap. Hear me on this: nothing will ever be perfect. And the longer you wait for perfection, the more likely you are to lose whatever competitive advantage you have today. Don’t wait for perfection and don’t use experimentation for bug fixing. You and your customers deserve better than that.

Ask How Teams Solve Problems

Next, you’ll want to dig deeper into their product development process. Don’t rely on surface-level answers; push your interviewers to describe how things work day-to-day. And don’t just rely on the PM to tell you.

Questions to ask:

1) How do you take a product from discovery to delivery? What role do different functions play in the process?

Collaborative, end-to-end involvement from all functions leads to better alignment, shared ownership, and successful outcomes when building products. Remember, silos don’t work. A siloed development process is messy, unproductive and ripe for finger pointing.

🟢A Great Answer:

"The team—including design, engineering, and product— iterates together during discovery to understand customer needs, co-design solutions, and ensure feasibility before moving into development. Each function plays a unique but collaborative role: product ensures alignment on the problem and priorities, design brings customer-centric solutions to life, and engineering contributes technical feasibility.”

*gets on soapbox* The best teams have engineering and design in product discovery meetings. The entire team is knee deep in customer problems before any discussion of solutioning happens. Teams that start discovery together, finish delivery stronger. If your engineers aren’t participating in discovery, you are only getting half of their value. Invite your engineering lead to the next product discovery kickoff and watch how your solutions become more viable in delivery.

🟡A Good Answer:

"Product, design and research focus on discovery so that engineering can focus on coding. Each team stays in their lane without much overlap so we can be more efficient."

This is better, but not great. I’ll say it again for the people in the back: You are not getting your money's worth by relegating your engineers to coding only. Full collaboration isn’t just product and design, its product, design and engineering.

🔴A Bad Answer:

"The PM writes detailed requirements and hands them off to engineering to build. Other functions get involved only after development has started."

This is what we call waterfall development. More often than not, I see teams trying to disguise themselves as agile, but really they're a waterfall team. A PM that makes decisions on their own and tells people what to do is a sign of an organization that doesn’t think about the holistic customer experience. Yes, the PM is the voice of the customer, but if design can’t speak to the user experience and engineering can’t speak to the feasibility, you will not build a solution that is strong enough for your customers. Full stop.

2) What happens when things go wrong?

An honest reflection on challenges is a sign that there's grace given and a desire for improvement. It’s also a great way to unpack how stress manifests through an organization.

🟢A Great Answer:

“We have open regular retrospectives, pre and post mortems. We solve things that aren’t working and we bring action items into our future sprints.”

Open retros and pre/post mortems are inclusive and solution oriented. Product teams don’t operate in a vacuum, so bringing in stakeholders, relevant SMEs and operators is a surefire way to improve. If you’re not noting action items and holding your teams accountable to those in following sprints, you’ll continue to make the same mistake over and over again. I believe that’s the definition of crazy-making.

🟡A Good Answer:

“We have regular retrospectives for our product team.”

This is great but what do you do here? Is it a vent session? It is a game of finger pointing? Identifying what went wrong is a great start, but it's just a start. Take it further and do something about the problems you’re seeing pop up in your process.

🔴A Bad Answer:

"We don’t really talk about what’s not working unless there’s a major issue."

Sure, if it ain’t broke don’t fix it. That doesn’t work when you’re combatting scale - in customers, team members, dependencies. Just because nothing is wrong doesn't mean you shouldn’t look at it. You may even uncover processes working so well that you can share them with other teams. While shit might not be hitting the fan, it doesn’t mean it's not worth understanding what’s happening. It’s not a process for the sake of process. It’s just an intention. And intention is always a good thing.

Ask How The Company Decides Which Problems to Solve

Finally, get to the root of the product-led culture and ask how decisions are made. Get deep into decision making and repeat the question for big projects and small projects.

Questions to ask:

1) Where do ideas come from? Who decides what gets built?

A healthy product culture encourages ideas from anywhere. Relying solely on leadership or investors is short sighted. Empowered teams take problems and decide what solution makes sense rather than taking orders to build a specific set of features.

🟢A Great Answer:

"Ideas can come from anywhere—teams, customers, leadership, and even support interactions. Leadership provides the strategic vision and high-level priorities, but teams decide what gets built by balancing customer needs, technical feasibility, and business goals."

With a strong vision, good leaders know that the best ideas come from anywhere. It’s why companies fund hack weeks and why the best leaders don’t tell teams how to build. Operators know the viability of certain features. Leaders who empower teams to make decisions on how to build end up with better products.

🟡A Good Answer:

“We say that ideas can come from anywhere but in reality our CEO’s ideas get prioritized over everything.”

This is a good distinction to make. Be sure to follow up with multiple team members as to what actually happens. While ideas can come from anywhere, it's important to ask what happens most of the time. Because that is most likely to be your lived reality.

🔴A Bad Answer:

"Our CEO built our roadmap. The CEO decides exactly what gets built, and the teams are tasked with execution. There’s little room for input from other stakeholders."

Sure this works when the company is small but as a company grows, a CEO that doesn’t hire operators she trusts is a bad situation for everyone involved. The best thing you can do is get clear on how hands-on your CEO is with the roadmap.

2) How do you set goals within the organization? How closely are they tied to the product vision?

Top-down goal-setting without team input or a connection to the product vision can make for a messy situation. This is a great way to figure out how the company holds teams accountable and how closely it connects to a strategic product vision.

🟢A Great Answer:

“The company has a yearly goal setting exercise. Leadership sets high-level objectives tied to the product vision and broader company goals. Teams then define their own key results."

The best teams have goals that tie deeply to the product vision. It’s a sign that your product leader, i.e. a CPO, is working in lockstep with the CEO to ensure that the product work powers the vision. Measurable OKRs that connect to a defined product vision give teams the confidence they need to build.

🟡A Good Answer:

“We have leadership set OKRs but then we have revenue goals that don’t totally connect.”

Often it is the case that team goals exist but don’t perfectly ladder up to the company strategy. This happens for a variety of reasons but it causes confusion, especially when teams have to make tradeoff decisions around the work they do. If there’s misalignment, get clear on why that’s the case and if there are efforts to remediate this.

🔴A Bad Answer:

"We’ve got some KPIs that change on a quarterly basis.”

If you don’t know what the goals are let alone who sets them, it's going to be difficult to define what success looks like in your role. KPIs are important but they aren’t longstanding. If someone can’t tell you about their goal setting practices, beware.

Bonus Beyond PMs: What About Your Growth Potential?

Beyond the product process, here are some bonus questions to help you vet what kind of organization you’re walking into. Shaky answers to these questions indicate that the hiring manager is not thinking about nor invested in a candidate's long term growth.

Questions to ask:

1) Who was responsible for this work before? Why are they hiring now?

Understanding the history of the role provides insights into organizational priorities, potential challenges, and the dynamics of taking on a new position. Vague or dismissive answers are a red flag.

🟢A Great Answer:

"You’re stepping into a role previously held by someone who transitioned into a new opportunity. They left behind a strong foundation but also some areas for improvement. We think it has the potential to become its own product area."

Aside from the honesty, the biggest highlight here is that it’s clear they’re thinking about how to develop this future employee. They aren’t simply backfilling a role. They’re thinking about it in a new way. There’s excitement, expansiveness and opportunity.

🟡A Good Answer:

“The last person didn’t work out but we know we hired incorrectly and we’re clear on what we need for this role now.”

Backfilling for a role where someone else was fired can be daunting. However, an honest conversation about what went wrong - in a respectful way - can be a trust building exercise that helps to unpack how the hiring manager navigates challenging situations. It’s also great insight into expectations and how those have evolved.

🔴A Bad Answer:

“The last person didn’t work out. We just need someone to take over quickly."

This is a reactive, short-sighted answer. It leaves you wondering about future growth potential. Without stated investment and prioritization in a candidate's career growth, it's unlikely to suddenly become a priority. It’s a sign that career growth might be an uphill battle.

2) What does success look like for this role in one year?

A clear vision of success demonstrates thoughtful planning and realistic expectations. Vague or overly ambitious answers can indicate a lack of clarity or unreasonable demands.

🟢A Great Answer:

"In a year, we’d expect you to have built trust across the organization, streamlined our product processes, and contributed to both short-term wins and a long-term product roadmap that excites our customers and stakeholders. We hope you'll start building your team."

This answer incorporates both product and career growth goals. Showing that they’re thinking about both and how to invest in you as a leader is a great sign. Dig into what you think some of these wins might be or how they envision a team expanding.

🟡A Good Answer:

"We’re expecting you to completely transform the product in your first year, delivering three major launches while solving all our current challenges."

We love ambition but this is likely out of step with reality. Probe the hiring manager to understand what transformation looks like and if you’d be set up for success given the resources and team available to you.

🔴A Bad Answer:

"We haven’t really thought about that—just getting things done is the goal."

A hiring manager who’s not thinking about your long term success is a red flag. If they’re hiring you to put out fires and have no idea what you’ll do after you after you get them under control, it might be hard to get the company to invest in your future growth. It’s not impossible, but it’s not a great sign.

---

Being intentional about these questions and your search process will help you find roles that align with your values and goals.

Because at the end of the day, finding a truly product-led culture isn’t just about the work—it’s about finding a place where you can thrive.

---

Jori is a Product Coach based in NYC. She writes Product Therapy, hosts Product Leadership Breakfasts and coaches Product Leads and their teams. You can get in touch with her here.