Gardening Your Product Process
- some conversations with startups where I found myself saying that lots of process varieties are possible/reasonable, that you iterate your way there via outcome metrics and retrospective;
- John Cutler's Messifesto ((2022-01-02) Cutler The Messifesto), and some tweets I spewed at him in previous days/weeks
Some thoughts to integrate:
There may be a range of reasonable values (deploy 2/day vs every-2-days), but there's a point where you've gone un-reasonable (2wks for most companies is a smell).
- see (2015-06-05) Cagan Product Fail
- hmm has anyone written a Waterfall Pattern Language? I don't see one.
- how about for Dark Agile? :)
You should understand the JTBD for every practice you adopt.
- so there should be a different language for each context-type
- and then you don't have to use every practice within that language.... but you should use more than 1... and if you're using practices from a different language, that might be an issue...
You should add/drop practices via retrospective. Every change is an experiment - while you might not rely on quantitative outcomes, you should document what you expect to improve, and what you expect might get worse, before you start, to drive your post-change review.
The current practices should be documented. As should reasons/history of changes.
If you have multiple teams working on the same product-line, how much do you want their practices to vary?
- Maybe the Community of Practice of PMs/TeamLeads should discuss this.
- Non Product/dev executives should not be driving this, though the CPO should be prepared to "sell" this model all the time.
- related/update: found this thread about (macro) process Change Agent pitching, including