Sam and Ryan talk about the cost of using engineering as discovery, the consequences of embedding product decisions throughout the design and development phases of a project, and other lessons that software engineers can learn from product developers. They also chat about how they categorize Github issues.
Topics:


0:00 – GitHub issue categorization

The importance of issue triage
Prioritizing bugs over features
Getting Things Done



7:53 – Managing product

7:53 - Engineering issues as a symptom of product/process issues
13:05 - The 3 phases of a software feature: product, design, engineering
16:04 - What happens when you embed product decisions in the design/engineering phases of a project
29:27 – Who's the head of product? Design? Engineering? Who is the decision-maker?
31:22 – Falsely believing that all decisions are final. Stakeholder PTSD.
34:07 – Product and marketing decisions are getting made, whether you are making them explicitly or not.
37:00 – If we care about people being successful with Ember, we need to understand the product decisions that are being made on behalf of Ember. In OSS, we are making product decisions whether we realize it or not. Are we making them as a side effect of our work? If so, we could create better software by thinking explicitly about these decisions.
41:04 - What do you do when you've gone through this phase and you learn something new?
41:55 - Small batches (Lean startup). Envelope example. Unknown complexity at the end of software projects.
45:28 - Getting a cross-discipline team in the same room. Having a decision-maker to avoid design by committee.



Links:

The Lean Startup by Eric Ries