Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Product Development Processes You Might Not Have Heard of (2022)

departmentofproduct.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Product Development Processes You Might Not Have Heard of (2022)

#21

Post by seamossfet »

adamtaylor_13 wrote: post #18

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.

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.

Re: Product Development Processes You Might Not Have Heard of (2022)

#22

Post by jgoldfar0nil »

hiAndrewQuinn wrote: post #16

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 y…

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?

Re: Product Development Processes You Might Not Have Heard of (2022)

#23

Post by toyg »

hobs wrote: post #20
toyg wrote: post #9

Earlier quoted context omitted.

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.

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 generall…

> 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.

Re: Product Development Processes You Might Not Have Heard of (2022)

#24

Post by Xiol32 »

contingencies wrote: post #19

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.…

The phone thing is weird given you treat everyone like adults otherwise.

Re: Product Development Processes You Might Not Have Heard of (2022)

#25

Post by mindcrash »

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

Re: Product Development Processes You Might Not Have Heard of (2022)

#26

Post by gcanyon »

rocqua wrote: post #12
recursivecaveat wrote: post #4

Earlier quoted context omitted.

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.

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.

On this project we're presenting to users two to three times a week -- not to the same user, the most frequently that we demo to a single user is about every two weeks, but there are a few we exchange notes with weekly.

Re: Product Development Processes You Might Not Have Heard of (2022)

#27

Post by gcanyon »

zero_shift wrote: post #13
rocqua wrote: post #12

Earlier quoted context omitted.

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.

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 proces…

Most of the scrum projects I've worked on have been for mass internet users, where feedback came in the form of AB test results. Our current scrum process includes close review with customers, albeit not on a strict two-week/sprint basis.

Re: Product Development Processes You Might Not Have Heard of (2022)

#28

Post by greggsy »

asplake wrote: post #8
greggsy wrote: post #5

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.

> 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…

> There are theoretical limits on what formal organisational systems can achieve in terms of information flow

Well put. There's just too much going on in some organisations for leadership to make meaningful decisions. Your comment reminds me of the Viable Systems model, which was a welcome gem hidden away in (the other) Michael Jackson's systems thinking slab of a textbook.

My go to means of ensuring that executive (including me) can keep their finger on the pulse is to encourage people to be open in large and informal chat platforms like Teams and Discord.

Re: Product Development Processes You Might Not Have Heard of (2022)

#29

Post by contingencies »

Xiol32 wrote: post #24
contingencies wrote: post #19

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.…

The phone thing is weird given you treat everyone like adults otherwise.

Agree. Good reasons, not worth elaborating here.

Re: Product Development Processes You Might Not Have Heard of (2022)

#30

Post by hobs »

toyg wrote: post #23
hobs wrote: post #20

Earlier quoted context omitted.

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 generall…

> 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 metaphoric…

Honestly it sounds like you have a bit of a management problem if your engineers are building random stuff you don't need. I spend a decent amount of my time behind the scenes with the PM folks making sure the things we are building are the things we want to build, and then convincing people (often in a face saving manner) that what the business wants is what we all want (since they pay us.)

This generally works because I target the smaller companies and so actually making money is at issue, in a large enough org you can go half a decade before anything shakes up dumb stuff.

Post reply on HN