SVPG · Free post · Discovery & customer research · Execution, roadmaps & process

Discovery vs. Design

Marty CaganJul 9, 20213 min
SourceSVPG
KindFree post
PublishedJul 9, 2021
Originalsvpg.com ↗
N:

Marty Cagan asks whether product discovery applies to feature teams, which are handed a list of features rather than problems to solve. At a simple level, discovery is irrelevant there because the solution is already chosen. He then complicates that answer: stakeholders implicitly own value and viability risk, leaving feature teams responsible for usability and feasibility, so some discovery-like skills remain relevant. He argues that discovering an effective solution is a much harder skill than designing a usable experience or feasible architecture for a given feature. Accountability also differs, since on a feature team failure falls on the stakeholder, while empowered teams own outcomes. He suggests PMs on feature teams can earn the chance to tackle harder problems by showing business and customer understanding.

01Key takeaways

  • Discovery means finding a solution to a problem, which feature teams usually don't get to do because the solution is handed to them.
  • On feature teams, stakeholders typically own value and viability risk, while the team owns usability and feasibility.
  • Usability and feasibility work builds useful skills, but discovering what to build is a substantially harder competency.
  • Accountability for results sits with whoever chooses the solution, which makes empowered teams accountable in a way feature teams are not.
  • A feature-team PM can earn more discovery responsibility by showing command of business viability and real customer needs.

02Key sections

The simple answer
Discovery means finding an effective solution to a given problem. Empowered teams receive problems, while feature teams receive predetermined features and roadmaps.
Where discovery still applies
Stakeholders take on value and viability risk, leaving feature teams to handle usability and feasibility, so some discovery-adjacent work remains.
Skill and accountability gap
Designing a feature is far less demanding than discovering a solution, and ownership of outcomes is what separates the two team types.
Earning the chance to change
PMs on feature teams can persuade leaders to let them tackle hard problems by demonstrating business understanding and deep customer insight.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

“the defining characteristic of a feature team is that the team is not given problems to solve”Marty Cagan · SVPG
“if our solution does not achieve the necessary outcome, that's on us”Marty Cagan · SVPG
“it's one level of skill to design a usable experience (designers) and a feasible architecture (engineers) for a specific feature, but it's a whole other…”Marty Cagan · SVPG

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.