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
- 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
- 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..
– Specify product to build
– Write code
– Test working software
– Document product
– Manage product delivery
– 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.
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.
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.
- – Bare necessity – Minimally Demonstratable Product – Make is describe the function, assess if it delivers the intended value
- – Capability and Flexibility – Options and Sub tasks – Make it complete
- – Safety – Make it bullet proof
- – 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.
– 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.