This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast, Shane Hastie, InfoQ Lead Editor for Culture & Methods, talks to David Hussman, founder and “The Dude” from DevJam and CardBoard It!, a tool for story mapping.
Key Takeaways
- Put value first – it’s not about building more stuff but making sure we build the right thing for the right people
- Dude’s Law: Value = Why / How
- Identify the impact that a product needs to make on someone’s life
- Constrain complexity using thin slicing and “minimum viable learning”
- Have an intentional discovery-delivery cadence to speed up the learning cycles – design and delivery sprints tightly coupled
- “Done” is not enough – value is only delivered when the item has been validated with real customers
- Validation can happen in both discovery and delivery
Subscribe on:
Notes
1m 09s The focus is starting to move from building stuff to building the right stuff.
1m 41s Introducing “Dude’s Law”: Value = Why divided by How.
3m 02s Think about the intent, not the process, when looking at product development.
3m 17s Focus on Product over Process and finding the intent, identifying the impact that the product will have.
3m 30s Large “transformations” are often never-ending and not very successful; successful products come from finding the thing that impacts someone – that makes someone’s life better.
4m 00s Announcing a new book underway on the topic, called Product Over Process.
4m 28s We have come close to killing the word “agile” through overuse.
4m 40s If products are valuable then we need to find the right mapping between teams, their products and their technology.
5m 00s The simple “one team, one tech, one product” viewpoint is simplistic and not realistic in today’s complex world.
5m 27s The challenges of extrapolating to one product and many teams and most complex of all is the large “system” based organisations where the products are not clearly visible.
6m 02s Accidental complexity (quoting Fred Brooks) or “incidental complexity”.
6m 35s Techniques to overcome the complexity such as MVP and small product slices. Treating customer journeys as “minimum viable learning”.
6m 43s Complicated problems are solvable, whereas complexity defies solution.
7m 08s Exploring the ideas around minimum viable learning – eliminating uncertainty.
7m 37s People often overcomplicate the MVP rather than treating it as a technique for learning.
7m 55s Using techniques like story mapping to identify the smallest chunk that will enable validation with a real person, even if it is not put into production.
8m 35s Learning outside of production, but not repeating the mistakes of the 90’s when prototyping meant “crappy code that we shipped and then suffered through”.
8m 50s The tools available to us today enable high quality, rapid development which in turn enables an intentional discovery-delivery cycle.
9m 09s Narrow the uncertainty outside of the delivery space through techniques like real time prototypes, A-B testing and customer interviews.
9m 25s More software developers need to move towards being product developers, learn what people’s needs are and validate at least some of them outside the code.
9m 54s Tackling the misconception that this approach is big design up front.
10m 00s The difference is the percentage of time spent in design and discovery.
10m 08s Using design sprints to inform the delivery sprint, narrow the level of uncertainty in the design sprint and validate things learned in the delivery sprint and then feed back the new uncertainty to the design sprint, an ongoing ebb & flow rather than serialised events.
11m 08s The difference between “done” and “validated”.
11m 25s Using the idea of validated to move towards test-driven-product.
11m 40s The idea of “impact driven development” – identify how you will measure it before you start building the piece.
11m 55s Getting to early validation in discovery or production validation in delivery.
12m 07s Done often means “I got it out there” without assessing the value delivered; product management starts with validation, not just building something.
12m 50s The challenge of linking the desired impact to the backlog items.
13m 10s There are a handful of small, naturally nimble groups who are already taking this approach but most organisations are struggling to grasp the concepts (eg Netflix).
13m 35s How Netflix can use data to inform their product design, because they have a solid technical foundation.
14m 10s The huge slope when going from a one-team, one tech-stack organisation to larger, more complicated environments with many teams working on a single product.
14m 35s Looking for evidence of success to identify a starting point for improvement in organisations.
15m 15s Find a starting place that is not so complex that you can’t apply some constraints, but is significant enough that achieving the outcome is non-trivial.
15m 30s We need to show the people outside of the delivery teams the value of the way of working.
16m 30s In complex organisations the idea of “product” is not obvious – helping people in the IT world move from project thinking to product thinking.
17m 44s The complex tech stacks that make up the ecosystem in many large organisations results in separation based around technologies and teams.
18m 13s Tease out the end-to-end value by identifying the essence of the service or product that is able to be validated.
18m 40s Through our approach of stubbing the different components while developing products we haven’t wielding the tech stack very well.
19m 00s Wield the complexity in the tech stack through slicing the delivery very thinly and validating frequently.
19m 30s Be prepared to use the discovery activities to validate the learning early and not build the wrong thing.
19m 40s Working out how to apply design of experiment in the digital space – start your experiments with clarity in the parameters you are working with.
Mentioned
- DevJam
- Fredrick Brooks
- Story Mapping
- Netflix
- Ted Talk: How to use data to make a hit TV show
- Nassim Taleb “evidence of success”
