Read on Twitter
1/6 
There's a lot of counter-intuitive fallacies in Product&Tech departments. For instance:
- You can totally decouple product from tech ("That's up to you, <tech folks>")
- You can increase velocity, working on a 20y/o monolith, by adding more people
There's a lot of counter-intuitive fallacies in Product&Tech departments. For instance:
- You can totally decouple product from tech ("That's up to you, <tech folks>")
- You can increase velocity, working on a 20y/o monolith, by adding more people
2/6
- You can attract good software developers showing videos and goodies, without a proper career plan or a sane tech stack
- You can have 5 priorities at the same time
- "We *need* this feature to be competitive"
- "We *need* to stop development 6 months to refactor this"
- You can attract good software developers showing videos and goodies, without a proper career plan or a sane tech stack
- You can have 5 priorities at the same time
- "We *need* this feature to be competitive"
- "We *need* to stop development 6 months to refactor this"
3/6
Product and Tech cannot be separated. They need to understand each other and to acknowledge current limitations and how to solve them *together*. Limit WIP; start pulling, not pushing; address tech debt *together*; trade-off product & tech *together*.
Product and Tech cannot be separated. They need to understand each other and to acknowledge current limitations and how to solve them *together*. Limit WIP; start pulling, not pushing; address tech debt *together*; trade-off product & tech *together*.
4/6
It's tempting to separate those in order to avoid hard conversations™. However, in the long-run, this will do more harm than good. Have those conversations. Ask for empathy. Talk business. Be empathetic. Reach compromises.
It's tempting to separate those in order to avoid hard conversations™. However, in the long-run, this will do more harm than good. Have those conversations. Ask for empathy. Talk business. Be empathetic. Reach compromises.
5/6
If you don't do this, *both* your Product and your Tech (hence your business) will rotten to death. First, it will be difficult to hire new Software Engineers and good Product people. Then you'll try marketing campaigns and throwing money (or more people) at it.
If you don't do this, *both* your Product and your Tech (hence your business) will rotten to death. First, it will be difficult to hire new Software Engineers and good Product people. Then you'll try marketing campaigns and throwing money (or more people) at it.
6/6
Usually, this means to be disrupted by new competitors that don't have this organizational/tech/product debt on their shoulders. That's why it matters to have people in the P&T department that understand how we can work together with each other.
Usually, this means to be disrupted by new competitors that don't have this organizational/tech/product debt on their shoulders. That's why it matters to have people in the P&T department that understand how we can work together with each other.
Keeping the spirit of the original thread: one of the most counter-intuitive things to acknowledge is that sometimes going slower means going faster.
Gitlab and Github are two good examples of this. Once they entered the "new features above everything" spiral, they had more and more serious outages. Do you think their costumers were then happier? Does it matter to have a new feature if you can't rely on the service working?
Focusing on one thing at once and limiting WIP *is hard*. Also, not shipping a new feature for the sake of making your product more sustainable to build is also creating value for the company.
When people say "only if we had this feature we'd beat the competition" I usually call it bullshit. Especially true if your product already has market-fit and you have tons of users. iOS didn't have copy-and-paste for years. Focus on the unique selling proposition.
