This week we discussed sections 3.1 and 3.2
3.1 — Introduction to Systems Thinking
- Jamie has had experience with this when studying geology and rock weathering; you have to think at a different scale.
- For reference, here is Wikipedia’s page on systems theory.
- A flow is a rate, and a stock is a quantity. Keep your deploy rate consistent and have stock of ready commits. You could choose to have no new deployments until a defect rate gets below a certain level.
- “Creating an arena for quickly testing hypotheses about how things work…” Geoff likes this idea. It’s visual, it’s theory of constraints, and you can be experimental about it using data instead of intuition.
- Houston asked if anyone has modeled this out on paper. Jamie said he’s seen resistance to it as people get defensive; people struggle with wanting things documented. Jameson wondered whether this would cause analysis paralysis, or if it would relieve that paralysis.
- Some visualization tools…
- Developers don’t like to create these flowcharts because “the code is document.” However, working software over documentation doesn’t mean no documentation.
- These stocks and flows are tangible things you can measure.
3.2 — Product management: exploration, selection, validation
- Dennis said this book would have been useful in June 2019 because he changed to a product owner from a tester, and has since moved back into a more technical role. “This can be exciting, and yes this can be a time when ‘exciting’ rhymes with ‘terrifying'”.
- Jamie likes talking to users, but doesn’t like talking about marketing and managing work items. He also favors working with internal customers.
- Jameson said there are very few people that understand what the market needs. You need to be deep in the problem space. A product manager sits at the macro and micro level.
- You need rigor around what you’re going to build and get coordination and agreement. The most important thing is the pick the problems that you want to solve.
- Not many of us had heard of an economic moat to protect yourself. You need you core business to be protected so you can try other things.
- It’s good to be a leader in a given market, but you need a plan to diversify or pivot. Spend time innovating in that market to keep being a leader. We chatted a bit about iPhone and Android and types of stagnation and innovation.
- Jameson appreciated the “winning rounds” statement. It’s nice to survive a round, but it’s better to win. This builds trust with your team and your stakeholders. Eventually the losses become not as detrimental.
- Houston talked about the “customer letter” — what would you write for your launch announcement? Does a product manager do this or marketing? We’ve seen this more as presentations of where we want to go.
- Geoff asked whether the author was correct in saying that there’s misinformation at conferences. There are some people that have only scratched the surface vs. having deep experience. Having good ideas is different than having years of experience. Jameson has experienced more value talking to the speakers instead of listening to the talks.
- Experimentation over analysis is an interesting way of framing it. Analysis can also cause problems because of confirmation bias and knowing when to stop. This is similar to what’s covered in The Lean Startup with A/B testing.
- People rarely think about the switching costs. Is it worth the long-term investment? Jameson said that these discussions need to be in business language.