Yesterday I had a conversation with an R&D leader at a sales-led company making the shift to product-led. They were a profitable retail software company who had grown through the efforts of their sales department. The sales reps built strong relationships with potential clients and closed the deals by promising the new features the clients asked for. As a result their product org was operating from the backseat, mainly project managing the agreed tasks. Only a handful of people in the R&D org knew mature product development.

And now the heads of product and engineering were working closely together to shift the company from overly sales driven to product led. They were already thinking about setting up new roles and ways of working and how to get the rest of the exec team onboard.

The question they asked: “We know we need to change a lot of things. But where do we start?”

My answer: Start with product discovery in the teams. Tomorrow.

The Problem: What Happens When Sales Is Overly Driving

When sales drives the majority of the roadmap and product teams execute what was promised, you end up with:

Risk of building a FrankenSaaS​
Without intentional product strategy, your solution becomes a disconnected collection of features that don’t form a coherent whole. New customers see a confusing interface with capabilities they don’t need while missing ones they do.

Hard to scale​
• You develop features that serve one customer but don’t fit your broader user base
• Your team spends 60-70% of their time on customer-specific requests instead of building horizontal value
• Your codebase becomes fragile, every change risks breaking someone’s custom workflow
• Your sales cycle gets longer because you’re selling customization, not capabilities

Business impact​
• Revenue ceiling: You can only grow as fast as you can customize
• Margin compression: Engineering costs scale linearly with customers instead of logarithmically
• Competitive vulnerability: While you’re building bespoke features, competitors are solving core problems better
• Talent drain: Your best engineers and R&D professionals leave because they’re stuck maintaining Frankenstein code and delivering features instead of innovating

The strongest antidote to this way of working is finding a different way to understand what to build outside of picking from the list of requests from the customer.

What Is Product Discovery

This is the work before you start development where you look at where your business is heading, what metrics you want to push, what problems you need to solve, and start to ideate what solutions you could go for. This isn’t something you do alone in a room, you do it by observing customers and looking at data.

The core mindset shift: From “what did they ask for?” to “what problem are they trying to solve?”

When a sales rep comes to you with a feature request from a customer, discovery means pausing to ask: What’s the underlying problem? Who else has this problem? What are different ways we could solve it? Does solving it move our key metrics?

What you’re aiming for:​
Before any dev team starts building (costly!), you want to feel fairly certain that what they build will:
• Serve the business (viable)
• Serve the users (usable)
• Make sense from a technical standpoint (feasible)
• Solve an actual problem (not just deliver a requested feature)

Why Start With Product Discovery (Not Role Descriptions or Org Charts)

Yes, the shift to product-led requires multiple changes: new role descriptions, different success metrics, updated ways of working. It’s tempting to start with structure: role descriptions and RACI matrices. But all of this requires work and time, while not being particularly motivating to the people who don’t already know why the shift is needed and the joys of working in a mature product development process.

Also, for every day your product teams aren’t working on the right things, your company is missing out on impact. So meanwhile you work at the larger picture, kick off the teams on product discovery.

Among the product development phases—discovery (what to build and why), development (build it), and delivery (ship and measure)—discovery is where you decide what problems to solve and what solutions will solve them. Of all the things your teams could be building, discovery determines what they focus on.

This is where you make or lose the most money.

Why discovery first:​
• Discovery is the smallest change with the biggest mindset shift
• It’s cheap and impactful—you can start tomorrow without reorganizing everything
• It gives teams immediate agency and ownership
• Changes how you think about the work, which makes other changes flow naturally
• Creates a clear link between team work and business goals (teams become more connected and motivated)
• Shows quick wins that build momentum for bigger changes

The cost argument:​
• Cost of building the wrong thing: a few sprints of engineer hours wasted
• Cost of maintaining the wrong thing: ongoing drag on velocity and morale
• Opportunity cost: Building the right thing in the wrong way, or worse, building the wrong thing entirely while competitors solve real problems

Starting with discovery first lowers risk and makes everything else possible, it also helps development leaders and teams connect their day to day work to the why.

How to Start (Tomorrow, Not Next Quarter)

It takes time to build new habits, and getting into the weeds and actually doing the work beats any theoretical framework. Your teams will read the books, but meanwhile, kick off discovery work now. In a cheap and fast way.

For teams:​
Get them started on connecting to customers. It does not matter how you start, pick a current idea you’re working on and find a way to get it in front of your users. This is normally led by the PM together with peers from engineering, design and data.

• At a newspaper, this can mean going out on the street and showing a 2h prototype to people you meet with a few questions
• At a developer portal, it can mean taking the elevator to where the backend developer sits and asking a few questions to someone on a break
• At an audiobook company for kids, it can mean getting some co-workers’ children to drop by after school and test a new prototype
• At an enterprise company struggling with internal adoption of a platform, it can mean setting up 30 min interviews with VPs to drill into what’s holding adoption back

Bonus points for finding a way to capture this to share it with the rest of the teams (recordings are awesome but not always feasible).

For the organization (you):​
Find ways to encourage discovery. It can be part of what you track, it can be as simple as demoing and sharing the results from the sessions in your weekly syncs, or keep a list of prereqs for anything going into the teams’ sprint backlog (for a task to move to the sprint backlog it needs to be validated through epic reviews, strategy reviews, docs with the thinking outlined, checklists, etc.).

My whole point is: don’t wait until everyone knows exactly how to do perfect product discovery. Because change does not work like that. Instead, start small, start fun and let the powerful learnings from user interactions work their magic. Once you’ve experienced them, you’re never going back.