Product Development Processes You Might Not Have Heard of (2022)
departmentofproduct.com
Product Development Processes You Might Not Have Heard of (2022)
1–10 of 32 posts
Re: Product Development Processes You Might Not Have Heard of (2022)
#2In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:
1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs each have 2-3 items they are actively working on. 4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in Item 5 generally happens weekly, sometimes even every few days. They work fast.
Re: Product Development Processes You Might Not Have Heard of (2022)
#3Symantec, which once sold programming tools, tried a unique approach - scheduled maintenance. The product team worked on one product at a time. When they finished an update, they'd go on to the next product. Products were not updated out of cycle.
Re: Product Development Processes You Might Not Have Heard of (2022)
#4In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly: 1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs…
That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.
Re: Product Development Processes You Might Not Have Heard of (2022)
#5I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
Re: Product Development Processes You Might Not Have Heard of (2022)
#6I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
Re: Product Development Processes You Might Not Have Heard of (2022)
#7I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
You can only be productive 'talking about something' if you understand the concepts to later 'do what needs to be done'.
In the absence of tech leadership it might as well be magic. I wouldn't understand the working details of doctors or lawyers on a medical, or legal, project but you'd bet I'd be praying to any agile deity listening to drag it over the finish line, trusting that the profit margins would help obscure this uncomfortable reality.
Re: Product Development Processes You Might Not Have Heard of (2022)
#8I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
> but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
A few people might do that informally, sure, even as part of something bigger, but there’s no escaping the needs to 1) coordinate over shared resources and 2) organise around shared commitments. And where do those commitments come from? Implies some kind of strategising, and if that’s not a collective thing, then you’re relying on someone doing the telling. And of the options that are strategised, what’s acceptable and what’s outside our purpose, identity, etc?
There are theoretical limits on what formal organisational systems can achieve in terms of information flow (so managers shouldn’t over-depend on them), but nevertheless, the above activities are fundamental. Take any of them away and you no longer have a viable system, one capable of ensuring it’s ability to maintain itself, to act independently, and to increase possibility in a changing and perhaps hostile environment.
Disclosure: I have a book coming out on this stuff shortly, bringing some decades-old, well-tested, and well-regarded theory up to date. FWIW I also wrote one of the leading books on Kanban (2014), not that this changes any of the above, apart from that Kanban is among other things an effective coordination system (though incomplete in the above terms, but then so are all the others).
Re: Product Development Processes You Might Not Have Heard of (2022)
#9I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
I'm a newb PM and at the moment I feel like I have all three... It's hard to coordinate when developers are all headstrong seniors with big agendas. The best I can do at the moment is nudge some of them, occasionally, into doing some of the work I need, while hoping their goose-chasing eventually produces something I can sell to my bosses.
Re: Product Development Processes You Might Not Have Heard of (2022)
#10I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
And 4) individuals engaging multiple people or multiple people's worth of org resources into their initiative, only to get bored with it half-way in.
And 5), which is why we called this pattern a "do-it-cracy" in our Hackerspace - someone might do something and get 90% done before other people notice, and when they do, it turns out >50% of them absolutely do not want it, and would've objected given the chance.
(Then again, we've found that "do-it-cracy" can arise as a rebellion against excessive bike-shedding, which is something groups of people love to do.)