Too often, product discovery is seen as something only for Product Owners, UX designers, or business analysts. Developers are handed a list of features to build, rather than being engaged in the process of exploring what should be built and why.

This approach misses a huge opportunity—developers bring technical insights, problem-solving skills, and innovative thinking that can significantly improve product outcomes before a single line of code is written.

Engaging developers early in discovery:

• Prevents costly rework by identifying technical constraints before development starts.

• Encourages innovation by leveraging technical expertise to shape better solutions.

• Increases team ownership and alignment by ensuring engineers understand why they are building something, not just what to build.

Let’s explore why and how developers should be part of the discovery process.

1. Prevent Rework and Identify Risks Early

When developers are excluded from discovery, technical constraints are often discovered too late—resulting in mid-sprint surprises, wasted effort, and scope changes.

A developer engaged in discovery can flag risks and dependencies upfront, reducing the chance of delays later.

Example: A PO along with a BA proposes a real-time reporting dashboard, assuming it’s a simple enhancement. A developer in the discovery session points out that querying live data at scale will cause significant performance issues. Instead, they suggest caching the results every few minutes. This totally changes the design of the dashboards backend—solving the problem efficiently. If the impact was not understood and developers had just implemented as they were told then the impact would have negatively effected all users of the system.

2. Bridge the Gap Between Vision and Feasibility

Developers play a critical role in ensuring that product ideas are not just valuable, but also practical to implement.

Key contributions developers bring to discovery:

• Highlighting technical trade-offs: Can a feature be built in multiple ways? What are the pros and cons of each approach?

• Suggesting simpler solutions: Can we achieve the same outcome with less complexity?

• Uncovering dependencies: Does this feature require infrastructure changes? Will it impact other teams?

  
  

Quote from How to Succeed as a Product Owner: "Developers assess the technical feasibility of ideas, ensuring that solutions align with the product’s technical architecture and constraints. A well-refined backlog minimizes ambiguity, making development smoother and reducing mid-sprint disruptions."

3. Encourage Innovation Through Technical Expertise

Developers are problem solvers, not just implementers. When they are involved in early discussions, they often suggest creative technical solutions that others might not consider.

Example: A Product Owner wants to add a custom-built recommendation engine to an e-commerce platform. A developer suggests leveraging an existing API, significantly reducing development time and costs while still meeting user needs.

By engaging engineers early, teams can discover smarter, faster, and cheaper ways to achieve business goals.

4. How Developers Can Contribute to Product Discovery

A. Join Discovery Workshops

Discovery workshops bring together Product Owners, designers, and engineers to explore user needs, brainstorm solutions, and define priorities.

Developer contributions:

• Ask key technical questions: "How will this feature handle high traffic?" "What are the integration points with existing systems?"

• Suggest alternative approaches: "Could we use an existing tool instead of building from scratch?"

• Clarify assumptions: "Have we checked if this third-party API supports the required data format?"

  
  

Quote from How to Thrive as a Development Team Member in Scrum and Kanban: "Developers should work with Product Owners, stakeholders, and designers to explore multiple ways to achieve an outcome. A strong discovery process ensures the technical team understands the ‘why’ before jumping into the ‘how’."

B. Participate in Building the backlog with the PO

Backlog refinement, breaking down features into stories and stories into smaller stories is where broad ideas become actionable. Developers play a key role in ensuring the work is technically sound and achievable. The PO does not need to create every single story.

How Developers Add Value in Refinement:

• Create stories based on their role and findings during discovery

• Review acceptance criteria for clarity

• Highlight potential technical risks or dependencies from other stories

• Propose spikes to explore feasibility

  
  

Example: Instead of jumping straight into development, a developer suggests a one-day spike to test whether an API can handle the expected data volume.

C. Use Spikes for Prototyping and Validation

Developers can run small experiments (spikes) to validate assumptions, create mock ups, prototypes and more before full-scale implementation.

How Spikes Help in Discovery:

• Create prototypes

• Test new technologies before committing

• Explore performance constraints and scalability

• Investigate integrations with third-party services

• Study feasibility

  
  

Example: Instead of committing to a new AI-driven fraud detection system, a developer builds a lightweight prototype to assess its accuracy before full implementation.

D. Dual-Track Agile – Balancing Discovery and Delivery

Many teams struggle to balance exploration (discovery) with execution (delivery). Dual-Track Agile provides a structured way to integrate discovery as an ongoing process, rather than treating it as a separate phase. (The team members take turns being tin discovery - I usually try a 20/80 split Discovery to delivery)

What is Dual-Track Agile?

• Discovery Track: Focuses on research, validation, and defining what should be built.

• Delivery Track: Focuses on executing and developing validated solutions.

How Developers Contribute to Dual-Track Agile:

• Collaborate with the PO and UX team to refine ideas before they reach the delivery backlog.

• Run small, time-boxed spikes to explore technical feasibility alongside design iterations.

• Test prototypes and provide feedback on architectural decisions before full implementation.

Example: A development team working on a new user onboarding experience follows a 20/80 split between discovery and delivery.

• Developer A spends two sprints in discovery, collaborating with the Product Owner, Business analyst, and UX team to explore how to reduce onboarding drop-off rates. They investigate different solutions, run a spike to test a third-party authentication service, and validate feasibility and once agreed add stories to the backlog.

• Once the discovery phase for outcome A is complete, Developer A moves into back into the normal delivery track to help implement the validated solution.

• Meanwhile, Developer B transitions into discovery to begin researching outcome B, which focuses on improving user engagement post-onboarding.

This rotation model ensures that discovery is not separate from development but an ongoing, integrated process, allowing developers to shape solutions early and then carry their insights into the delivery phase.

Quote from How to Succeed as a Product Owner: "Dual-Track Agile ensures discovery is not a one-time phase but an ongoing effort, where developers actively help shape solutions before committing to build them."

5. Balancing Discovery with Delivery

Some teams hesitate to involve developers in discovery, fearing it will slow down delivery. However, balancing both ensures that teams build the right things, not just ship features quickly.

Best Practices for Balancing Discovery and Delivery:

• Timebox discovery efforts to avoid analysis paralysis. Example: Allocate two sprint days to prototype a new feature before committing to full development.

• Integrate discovery tasks into the backlog as spikes, research tasks, and validation efforts.

• Use continuous feedback loops to refine solutions iteratively.

  
  

Quote from How to Succeed as a Product Owner: "Discovery and delivery are not competing priorities—they are complementary. Balancing the two ensures that innovation doesn’t derail progress and that delivery remains focused on validated needs."

Final Thoughts: Developers Must Be Product Thinkers

A developer’s role is not just to write code—it is to build the right solutions that deliver real user value. Engaging in discovery helps teams:

• Reduce wasted effort by validating ideas early.

• Avoid technical debt by addressing risks before development starts.

• Innovate faster by leveraging engineering creativity from day one.

What’s Your Take?

• Does your team involve developers in discovery?

• Have you experienced a time when early technical input saved a new increment from disaster?

Drop your thoughts in the comments!

More Resources for Agile Practitioners

My Agile How To series dives deeper into these topics and more.