This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Rich Mironov about the current trends in product development.
Key Takeaways
- There is nothing more wasteful in the world than beautifully building a product that no one wants to buy
- Everywhere in the world engineering teams are similar to other engineering teams and sales teams are similar to other sales teams and the two groups are completely opposite to each other
- Dropping time and funding allocated to the quality/infrastructure improvements is similar to joining a health club and never going – you won’t get better and fitter unless you go
- If you can’t cope with the role which has lots of responsibility and little authority then maybe a product role isn’t right for you
- Bringing the dev team into close contact with customers has been a goal and a topic of conversation for a long time, but very few organisations are actually doing this
- Good product managers frame problems, they don’t demand features
Subscribe on:
- 0:25 Introductions
- 1:50 There is nothing more wasteful in the world than beautifully building a product that no one wants to buy
- 2:02 Engineering is not responsible for deciding what to build
- 2:18 Separate the high-level “what do we build” from the lo level “how do we build it and make it good”
- 2:38 The importance of loudly and frequently asking “why are we building this, do we know who wants it, where is the market for it?”
- 2:54 With an internal product ask about where the money saved will be reinvested, what budget will be reduced because of this new product
- 3:05 In most large organisations, IT builds things that are asked of them but has no ability to tie the costs to real savings or increased benefits
- 3:18 The responsibility of executives to decide that building this thing is a good idea, and that it is more valuable then the other good things we could build with this money
- 3:45 Every engineering team on the planet is fully occupied, so building something inevitably means not building something else, or stopping building something else
- 4:04 The painful reality that we need to have exclusive-or conversations about what to build
- 4:20 Advice to technical teams wanting to ask the hard questions and not being in the power structure to do so – approach it with lots of questions about who it’s for, what are the success metrics, how will users judge the product, how will it be supported …
- 4:48 The good product folk will respond to those questions and if they realise that there isn’t a valid value proposition the idea will be shelved
- 5:08 Many IT departments are treated like the local sandwich shop – other departments place demands because they have available budget, not because they have sensible product ideas
- 5:47 The need to get out from behind the deli-counter and into the strategy discussions
- 6:00 The cultural split between sales and engineering in software product companies
- 6:14 Everywhere in the world engineering teams are similar to other engineering teams and sales teams are similar to other sales teams and the two groups are completely opposite to each other
- 6:24 Sales teams in enterprise software vendors are tasked (and paid) with closing individual deals, and they will do so by promising capabilities and changes specific to that customer
- 7:16 Engineering teams are tasked to make products that are turnkey and packaged, a small number of excellent products sold many times with no change
- 7:48 The incentives and motivation of the two groups are in direct conflict
- 8:25 The dysfunctional behaviours this conflict results in
- 8:48 To overcome the challenge of the different viewpoints start by understanding the other’s perspective
- 9:12 Bridging this gap is really hard and is about people and organisational relationships – it’s politics
- 9:28 Explaining how to engage executives to look at the larger portfolio level picture
- 10:45 The importance of strictly allocating available capacity across roadmap features, technical debt reduction, improving infrastructure quality (eg implementing a DevOps pipeline), ongoing R&D and custom features for new deals and raising the level of the conversation about what custom features to build to the sales leadership
- 11:15 Dropping time and funding allocated to the quality/infrastructure improvements is like joining a health club and never going – you won’t get better and fitter unless you go
- 11:46 Portfolio thinking and constrained capabilities provide a platform for good decision making at the executive level
- 11:59 It’s not about the science, it’s about the psychology
- 12:10 Product people need to become great students of human behaviour and organisational dynamics
- 12:20 In the product job you often have limited authority and you need to lead by influence and evidence
- 12:32 If you can’t cope with the role which has lots of responsibility and little authority then maybe a product role isn’t right for you
- 13:05 The characteristics and behaviours of good product managers
- 13:32 The goal is to motivate people to do the best work they can so we can ship things customers love
- 13:46 It’s about getting good results, customers who love us and money coming in the door
- 14:25 Know the business you are in – are you a product company or a professional services company
- 14:38 Product company – build once, sell the same product many times
- 14:52 A product company needs a smaller team of great contributors who can build a product that the world wants and loves
- 15:12 Gmail as an example of a product where adding additional customers has effectively zero additional cost to the organisation
- 15:44 The contrast with a professional services company – they make money by renting out the time of their development teams
- 1:45 Professional services firms make money by giving the customer exactly what they ask for, irrespective of whether that actually adds value for the customer, and then charge them to change their minds
- 17:05 The difference in the things product and professional services firms focus on and discuss at the executive level
- 17:34 Professional services companies are successful when they have lots of people being billed out for their time and they do projects, not make products
- 17:52 Contrasting this with how product companies work and what they measure
- 18:24 Product companies don’t care about individual customers – change will only be made when there are thousands of customers who want that change
- 18:32 Product companies focus on building their core product really well, and look for off the shelf solutions for things that are not core
- 19:05 Either the professional services or product strategy can be effective; where companies try to do both they tear themselves to pieces and almost inevitably fail
- 20:25 Bringing the dev team into close contact with customers has been a goal and a topic of conversation for a long time, but very few organisations are actually doing this
- 21:20 Making talk to real customers frequently (outside of the sakes cycle) a KPI for product managers
- 21:45 Good product managers frame problems, they don’t demand features
- 21:57 Extending the customer engagement to include team members wherever possible
- 22:15 When engineers talk to customers you get better products – engineering teams are deeply passionate about what they do and want to build products customers love, and to do so they need to hear from real customers
- 23:35 Telling the story of Varian Technologies who build radiation treatment devices and bring patients to meet their development team – purpose driven motivation
- 23:40 Lots of bad excuses for not having development teams engage with real customers, it all comes down to a false view of cost savings
- 25:10 We know how to create great development environments and have engaged, motivated teams but somehow it feels “too hard”
- 25:34 If you think that typing is the same as developing software, then you want people to type faster and we know very well that this is not the case, but some organisations and some managers still seem to think this way
Mentioned: