Jeff Patton on Lean Product Discovery – when i grow up i want to be Jeff;jsessionid=F041DBCFAD1179C7F8B7DE9EBA018D08

Sometime you find something that manages to summarize all your disparate and random thought into one cohesive whole… and i was lucky enough to have that served to me on a platter by Jeff Patton.

I was so impressed i rewatched it and took some notes and stole some slides. Most of it was simply scribing what he said – so i lay no claim to any of the ideas. I’m simply praying at the Patton alter….. i think when i grow up i want to be like Jeff.

Anyway, here it is….


User Experience?…. I don’t even care about users

Lets not make this about users, lets make this about us. Let make this about “not making bad software” – bad… meaning useless in the real world, not delivering real value to its intended users…. Waste of time, waste of money… perhaps never released or just plain failed – more importantly… a wasted period of MY life.

You only learn how bad it is by watching

If you have never watch people try to use your software, you not really serious about software. Watching people trying to get value out of what your building is enlightening – its game changing…

In Product Development you are always trying to Balancing two concerns

  1. Delivery – building of a software product – easy to talk about – functions, code, testing,  – quantifiable, measurable. It’s easy to understand. Its tangible stuff – the solution – what your building
  2. Discovery – learning about the outside world and our product within in – its scary – deals with the real world, and the problem it’s trying to fix in that world – fuzzy, harder to quantify. Its about understanding how people try and extract value from what your building. Is what we built really good, does it really deliver value..

Delivery is…

–       Specify product to build

–       Write code

–       Test working software

–       Document product

–       Manage product delivery

Discovery is…

–       Understand customers and market

–       Understand competitors

–       Understand users

–       Distil business strategy into product strategy

–       Ideate product ideas

–       Prototype user experience

–       Validate prototypes with users

–       Create detailed UI design

–       Validate working software with users

–       Compare expected market results with actual market results after delivery

Discovery finds problems to solve and shapes solutions.

Discovery focuses on defining what value is, and how best to deliver that value to customers. Discovery and delivery are joined – figure out what to do, and then find a way to do it, and then once its done try and evaluate how well you achieved what you set out to do.

In the real world your Competitors are often pencil and paper, or human processes – they are simply the ways that people are doing what they are trying to do currently. You need to do better than this to add any value.

Plug discovery in early, during the build and after the build. Discovery is threaded in everything we do.

Undelivered software is a solution hypotheses

Undelivered software is a solution hypotheses, most of these hypothesis are incorrect. Focusing on discovery AND delivery in equal parts betters our odds of succeeding delivering REAL value.

Value Stream

Focusing on delivering value not functions widens the scope of what we need to do. This has a longer cycle time and has fuzzy ends. Discovery shapes our understanding of what value actually is.

Incremental development is often used to help us learn as we deliver BUT incrementing calls for a fully formed idea – incrementing needs strong upfront discovery.

During delivery we often fail to answer some critical questions – is this the right product (does the customers value this), is this product right (does in meet the quality wanted by target customers)

Balancing Discovery and Delivery

We usually start by throwing ourselves out of balance immediately – Most process lump all the discovery into upfront research, analysis and design – clunk.

Then we respond by weighting everything towards delivery – clunk

Then we deliver something, and we get feedback and we learn a bit about it – and we start to get more in balance – only we were not very efficient in delivering value to the end users. And we may learn to late that the initial discovery concept did not translate into what was delivered.

Iterating and incrementing

We need to Leverage discovery to iterate as we deliver….. Its not iterative if you only do it once.

Smoothing the flow of information between discovery and delivery…. Working in a more collaborative way, based on how the world might be with our product with it…. in order to release less of a hypothisis…

Expanding the scope of the card wall and agile management practices to include discovery

If we visualize the discovery tasks, the card wall gets wider…. and we need to visualize both discovery and delivery.…. Kanban helps smooth the flow through the card lanes.

Batch Size

Discovery and Delivery have different “natural” batch sizes

  • Delivery – Minimum Marketable Feature (Agile Stories – smaller)
  • Discovery – Minimum Viable Product (Release – larger)

Stories in themselves do not always deliver value to users – users don’t think incrementally – discovery is thinking at the macro level, delivery is thinking at the micro level.

User testing – you cant user test part of a process. User goals span multiple stories and discovery helps define this context – the Minimum Viable Product.

Breaking down larger features over iterations

the idea here is that any feature can be broken down into 4 different quality phases – and that by doing this you can move from incremental to iterative style development.

  1. –  Bare necessity – Minimally Demonstratable Product – Make is describe the function, assess if it delivers the intended value
  2. –  Capability and Flexibility – Options and Sub tasks – Make it complete
  3. –  Safety – Make it bullet proof
  4. –  Usability, Performance, Sex Appeal – Make it Desirable

Early stories bring up bare necessity across the entire Minimum Viable Product, iterate this in order to improve quality.

Reduce Uncertainty

–       Opening Game – Build up necessities

–       Mid Game – Build out flexibility and business rule enforcement

–       End Game – Refine the UX and interactions, take advantage of iterative learning

Discovery builds knowledge… The inverse of risk is knowledge – learn as much as you can about what represents real value in a product in order to reduce the risk of failure on release.

About Jason Furnell

design thinker . experience designer . lo-fi sketcher . workshop facilitator . visual thinker . diagrammer . agile believer . multidisciplinary collaborator . build sequencer . incrementing and iterating . architecting information . presenting and pitching . master of design (its a degree, not a self assigned title) . dyslexic . misspell-er of many many many things....
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s