[HN Gopher] Product Development Processes You Might Not Have Hea...
___________________________________________________________________
Product Development Processes You Might Not Have Heard of (2022)
Author : lgunsch
Score : 101 points
Date : 2025-02-13 17:40 UTC (3 days ago)
(HTM) web link (www.departmentofproduct.com)
(TXT) w3m dump (www.departmentofproduct.com)
| gcanyon wrote:
| In 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 < 10 seconds'") 5. When a dev puts
| something in for code review, if they're down to too few items,
| they check in with me to figure out what to add to their active
| list. We go over the outstanding list to figure out value vs.
| effort and make some choices.
|
| Item 5 generally happens weekly, sometimes even every few days.
| They work fast.
| recursivecaveat wrote:
| 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.
| rocqua wrote:
| Sprints should give natural points to present to the end-
| user. Presenting to the end user is essential to getting
| feedback, and getting feedback is essential to building
| something the end user will actually use.
|
| You can get feedback without sprints. But they make it
| easier, and encourage getting something in front of a user
| fast.
| jbreckmckye wrote:
| In fourteen years I've never seen a scrum project that
| includes user feedback.
|
| At best it led to a stakeholder demo where some business
| people would look at a form or something, ask some minor
| questions, then a new cycle would begin (with its context
| switching, planning stress and perverse JIRA games - all
| the negatives of Scrum).
|
| I don't think many companies use such regular user feedback
| in their development process.
|
| Perhaps it's that they don't need to? I actually think a
| lot of company dysfunction happens when the "official"
| system purports one set of goals (user feedback, regular
| pivots) but the "real" system purports others (executive
| driven initiatives, long sales cycles)
| Animats wrote:
| Symantec, 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.
| greggsy wrote:
| I 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.
| jdlshore wrote:
| 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.
| toyg wrote:
| 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.
| hobs wrote:
| As a sr eng, they've also probably experienced a bunch of
| PMs before, some good, a lot less so, all with their pet
| projects and agendas that next year will be entirely new
| and innovative and in the bin in 12 months.
|
| The best ones I have worked with are competent, they dont
| make me do their work, they keep their promises, they dont
| waste my time, they see organizational issues and take
| point on them, and they generally were unflappable in
| targeting organizational discomfort about tackling an issue
| or talking to so and so.
|
| This is really hard for someone jr to the space, but
| humility in the face of everyone's priorities is a great
| start.
| toyg wrote:
| _> next year will be entirely new and innovative and in
| the bin in 12 months._
|
| Yeah but my problem is that _they_ are the ones with
| grand visions that may or may not ever come to fruition,
| and _I_ am the one left with half-baked features that the
| business clearly needs to fix right now but are seen as
| unfashionable to work on.
|
| Recently I was at a point where I've suggested to onboard
| a junior resource to mop the metaphorical floor. I'm
| starting to think that, next time, I should ask to have
| different degrees of seniority in the team to make it
| more balanced.
| TeMPOraL wrote:
| 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.)
| intelVISA wrote:
| 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.
| asplake wrote:
| > 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).
| karhuton wrote:
| _> Scrum with 2 week sprints may work very well in larger
| corporates, but startups who need to pivot regularly and change
| direction may not be as well suited to such a fixed process._
|
| If your pivot frequency < 2 weeks, sprint length is not the
| problem.
| hiAndrewQuinn wrote:
| The "betting table" reminds me that I continue to think there's a
| large, mostly untapped market for good internal betting and
| prediction market software in large software companies. The
| primary problem around them seems to be psychological: it's very,
| very painful to lose a bet that feature X will be shipped by date
| Y in state Z, and even more painful to see your own track record
| of failures grow over time, even if you are also accumulating
| successes.
| jgoldfar0nil wrote:
| I like this concept - when isn't a commitment a bet that we can
| achieve Z by date Y? To make it concrete is not dissimilar from
| the other gamified features different work planning tools have
| been adding in recent years
|
| Your point about seeing the inevitable lost bets add up is well
| taken, though from what I have seen the healthy responses to
| loss tend to be close to "either we win or we learn".
|
| So you want your team to make smarter bets and win bigger over
| time, and/or learn more from their losses. Can a software
| product make that process anything but a burden? Is there more
| there than other types of performance incentive systems?
| holowoodman wrote:
| I'm a fan of https://programming-motherfucker.com/
| adamtaylor_13 wrote:
| My team (3 devs) has been using Shape Up since January and it's
| been amazing. I don't think I can ever go back to scrum.
|
| It allows devs to be creative, do what needs to be done, and ship
| a real feature. All without any product managers, and zero
| meetings.
|
| Corporate companies could never imagine not counting all their
| beans, but man it is so freeing if you have the option.
| seamossfet wrote:
| Same! I run the engineering department for a medium sized
| software consultancy, we're on contract with several large
| enterprises. In terms of output, we run circles around their
| internal delivery teams. Not because our engineers are better
| than them, we've just fully embraced shape up as our
| development process.
|
| This has also let us bid on projects as fixed rate instead of
| T&M since we budget time as appetite instead of how long we
| think something will take to build.
|
| There are still some hurdles we have to overcome, like we can
| still run into unexpected things that we didn't know about
| during the betting process, but deep behind the philosophy of
| Shape Up it feels like something that translates extremely well
| to more creative R&D development projects like what we do.
| contingencies wrote:
| Our (complex physical product in a combined design office /
| factory) method: 10 minute chat together in the morning, identify
| any problems we'd like help with, anyone can ask to change focus
| at any time. Sometimes a team works on the same problem, usually
| people take sole responsibility for something on their own but
| take it from and bring it back to the group to keep everyone
| vaguely aware of where things are going. We may state what we
| think we'll get sorted for the day and what we're aiming for the
| next few days or week. Rarely do we look beyond a few days
| because it's too vague/unrealiable. At the end of the week we
| quickie summarize what got done by email (way shorter/higher
| level than git logs). If there's an over-arching goal or time
| pressure everyone is informed and we work toward it. No forms or
| friction for lateness, leave, lunch, ordering stuff, printing,
| etc. People are judged on commitment, ideas and progress. Factory
| floor and equipment, design office and electronics lab all on
| site. No management except keeping a weekly journal for the
| team's aggregate progress, setting some priorities start of week,
| and compressing updates to stakeholders. Oh yeah, and mobile
| devices are locked in a cabinet at the front door during work
| hours - if you don't like it work somewhere else or take the day
| off.
| Xiol32 wrote:
| The phone thing is weird given you treat everyone like adults
| otherwise.
| mindcrash wrote:
| In case you are interested in Shape Up and want read more about
| it, Ryan Singer - the inventor of the methodology - has written a
| really great book about how they have been, and currently are,
| building and shipping products and features at 37signals.
|
| The book is called "Shape Up" (doh) and the electronic version is
| totally free:
|
| https://basecamp.com/shapeup
|
| I would also really recommend the rest of the books, lots of
| great thoughts on development and management from actual
| experience. Also free:
|
| https://37signals.com/books
___________________________________________________________________
(page generated 2025-02-16 23:01 UTC)