How to bring engineers into the product discovery process

Every month I teach a Tech Term You Should Know (TTYSK) and a tech essay to level up your technical literacy and communicate well with dev teams. Ask me anything and I'll cover it in an upcoming issue.

This issue's Tech Term You Should Know is "Portability". Scroll to end for learn more 👇

Carl Vellotti is a Sr. Product Manager at GoodRx and creator of Carl’s Newsletter. His mission is to create tactical, helpful, and fun resources that PMs can immediately apply to their day-to-day work and build better products (and also to make the best product memes on the internet). You can find Carl on X / Twitter, LinkedIn, and Instagram.

Some takeaways from our conversation:

1. Product discovery is not just having ideas or making things you think are cool–it's grounded in users and their problems.

2. Assumptions can be dangerous without validation.

3. Engineers are a underutilized source of great ideas. Use them.

4. Make discovery a shared team effort, not just a product/design activity. Engineers should be part of the process from the beginning, not brought in at the end.

5. Make space for discovery work for engineers. Don't let daily feature requests and bug fixes crowd it out.

Can you talk a bit about product discovery? What is it, what is it not, and why is it important?

Think of trying to solve a problem as entering unknown territory. You might have a map with a vague outline of what’s out there, and you might have an idea of what you’re looking for, but the only way to actually discover how to get where you want to go is by actively exploring the space.

That’s basically what “product discovery” is – exploring an unknown space to chart a path to success. Your tools for exploration are user needs, new ideas, prototyping, and iterating as you go.

Discovery is incredibly important because it reduces risk and increases the chances of success. It makes sure you have a solid map to rely on before you invest all your resources on a specific path.

How would you describe the product discovery process? What’s the right way to do it and are there any wrong ways to do it?

The goal of product discovery is to deeply understand user needs, problems, and behaviors so you can design solutions that truly benefit them. This involves a lot of upfront research and experimentation before committing to building anything.

Some good practices:

1. Talk to real users to understand their challenges and goals. Don't make assumptions. Use interviews, surveys, site visits, etc to get insights.

2. Identify the user jobs, pains, and gains. What are they trying to get done and what prevents them from doing so? Empathize with their situation.

3. Define the problem space before jumping into solutions. Resist the urge to start building too soon.

4. Come up with hypotheses and run experiments to validate them. For example, create prototypes or landing pages to gauge interest.

5. Iterate based on feedback. Treat ideas as hypotheses and let users tell you what resonates.

Some bad practices:

1. Relying solely on internal opinions rather than users

2. Skipping problem validation and going straight to a solution

3. Getting attached to your first idea rather than testing alternatives

4. Not seeking feedback frequently and incorporating learnings

The key is maintaining curiosity, talking to users, and staying flexible. Assumptions can be dangerous without validation. Avoid big bets without evidence. But do experiment quickly and often.

Why is it crucial to bring engineers into the product discovery process?

There are two main reasons including engineers in the product discovery process is so important.

First, imagine you’re a product manager who’s taken the time to deeply understand your users’ needs and you’ve come up with the best idea in the world. You have high confidence that it will solve all your users problems and be a huge success. But there’s only one problem – it’s completely impossible to build! Engineers will help ground discovery in reality and keep you from going down impossible paths.

Second, engineers are smart, dedicated people with deep familiarity with how your product really works. They’re an often underutilized source of great ideas. I can’t tell you how many times I’ve seen quick wins with huge impacts come from encouraging engineers to share their ideas.

What tips do you have for bringing engineers into the product discovery process?

Here are a bunch of tips:

• Make discovery a shared team effort, not just a product/design activity. Engineers should be part of the process from the beginning, not brought in at the end.

• Include engineers in user research activities like interviews, usability tests, and site visits. Seeing real users firsthand builds empathy.

• When brainstorming solutions, have engineers sketch and prototype right alongside product managers and designers. Don't limit their involvement.

• Frame discovery as identifying and validating problems, not presented solutions. Engineers will feel ownership over helping figure out the right problems to solve.

• Leverage engineers' technical expertise during discovery. Have them spike solutions to evaluate feasibility early on.

• Make space for discovery work. Don't let daily feature requests and bug fixes crowd it out. Protect time for engineers to discover.

• Involve engineers in synthesizing findings, defining success metrics, and framing what "done" looks like for discovery sprints.

There’s a lot of talk about protecting engineer’s time so they can spend as much time as possible coding and building core functionality. Do you agree with this?

People often make the mistake of thinking that if an engineer isn’t coding, they aren’t working.

This is a terrible mindset for leveraging an engineer’s unique skillset and way of thinking to build the best product most efficiently. In reality, while coding time is precious, some non-coding activities ultimately enable engineers to be more productive and build higher quality products.

Insulating engineers from customers and business context risks building products that don't fully meet needs. Some cross-functional collaboration is important.

Finally, engineer satisfaction often comes from having context, autonomy, mastery, and purpose. Strictly limiting work to isolated coding can negatively impact motivation.

What are some do’s and don’ts for bringing engineers into the product discovery process?

Do:

• Get engineer buy-in on the value of discovery before kicking it off

• Make sure engineers are part of discovery activities from the very beginning

• Have engineers collaborate closely with product/design in hands-on activities

• Leverage engineers' technical expertise to explore feasibility early

• Protect time for discovery work amidst competing priorities

• Frame discovery as identifying the right problems, not just solutions

• Celebrate insights uncovered during discovery

Don't:

• Only bring engineers in at the end to implement pre-defined specs

• Limit engineer participation to just technical feasibility spikes

• Make engineers feel like their coding time is being "wasted"

• Fail to explain why discovery work is valuable for the product and team

• Allow discovery work to be consistently deprioritized and descoped

• Neglect including engineers in synthesizing findings and framing problems

• Only celebrate shipped features, overlooking discovery insights

• Position discovery as a linear hand-off process with set phases

I need your help! How can I improve this newsletter?

I put in a lot of time and effort providing you with the best technical literacy content, and I need your help. Tell me how I can improve this newsletter.

Missed the mid-month PM & Tech Jobs Newsletter?

Looking for a new job? Our PM & Tech Jobs newsletter is issued monthly with product role job listings from senior to entry-level roles.